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)
  • 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
Discussions au sujet du plan de migration
#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.