Working Practices - GetPoplog/Seed GitHub Wiki

To be expanded!

Code Reviews

There is a presumption that all suggestions will be accepted. So if you are asking a question rather than making a suggestion, it's best to make that clear. Obviously if there's a problem, usually time and priority, then it may get deferred. If one really does not agree with some aspect of a suggestion then there's a moral obligation to respond with a wiki article filling in some aspect of definition-of-done.

This is a specific example of a general principle. We attach some explanatory activity to an unwanted behaviour. Partly this is because it deserves explaining and partly as a small penalty that nudges people towards the generally preferred behaviour.

Relic Code

Commented-out code is not generally acceptable. It only becomes acceptable when it is accompanied by an adequate explanatory comment that describes [1] why it has been retained and [2] why the if-false trick has not been used.

The if-false trick refers to deliberately disabling a piece of code by guarding it with a conditional that has an explicit false value. The advantage of the trick is that the code is still inspected by the compiler, tokenised, identifiers are resolved and type-checked. This protects against the relic code bit-rotting and becoming useless.