Programming style Duniter v2

Nodes Duniter-v2s
1

When reading Duniter v2 code, one aspect of programming style surprised me. It’s the use of variables representing something hypothetic instead of something real. Examples:

  • next_creatable_identity_on instead of last_certification_date (expressed in BlockNumber)
  • next_issuable_on instead of last_certification_date
  • removable_on instead of is_removable
  • expire_on instead of last_activity
  • first_eligible_ud instead of last_claimed_ud (or start of membership if no UD ever claimed)

At least this is consistant in the codebase, but it can be a bit unsettling at start. The reason why I prefer real variables is that it makes implementing edge cases easier (for instance changing the interval between certifications, changing the inactivity time before which an identity is forgotten…).

(just wanted to keep track of that)

1 Like
2

This is not always style, if this is used in the storage then it changes whether a change affecting the delay constants is retroactive or not.

It may also be faster: you need to compute the future date only one time when writing, instead of a lot of times reading.

I always hesitate which to choose, and for example there is one case (unrelated to Duniter) where it has a subtle but important impact: in Arduino. The clock overflows every 50 days (and the microsecond time after 1h) so you may have surprises when comparing times, depending on the method used.

2 Likes
3

An other thing that surprises me:

I would rather make that certification and identities optionally expire, with the block given explicitly.

4

Naming could be made more uniform:

  • do_apply_first_issuable_on
  • set_next_issuable_on
5 
impl pallet_duniter_test_parameters::Config for Runtime {
    // [...]
    type PeriodCount = Balance;
}

Why would a period count be a balance?

6

Balance is sometimes used for counting things. I agree this is weird, we should create dedicated types or at least something generic like Quantity.

3 Likes
7

TL;DR: there is a slight positive correlation between presence of English swearwords and code quality in open source C projects on GitHub.

Conclusion: swearing against bad APIs in comments makes you a better programmer, and Duniter’s CI should check the swearword density in the project.

2 Likes
8

Thank you for this precious information @tuxmain , I will try to apply this way of doing things, always with the quality goal in mind required for the Duniter project.

2 Likes