4 ms·
The practical/actionable advice from the article are these 4: (1) don’t prematurely optimize (2) avoid configurable functions (3) don’t break out functions (4)
by yawboakye 6y ago
The practical/actionable advice from the article are these 4: (1) don’t prematurely optimize (2) avoid configurable functions (3) don’t break out functions (4) don’t mix levels. Mainly because they’re via negativa (Don’ts) and allow no room for misunderstanding or misapplication.
As I’ve grown older I’ve come to hate functions of a certain length, and especially how conditions are used. I think the authors gets at this with the “avoid configurable functions” but if I were allowed to give it a new heading I’d choose “avoid conditions.” This is in keeping with the need for the law to be via negativa. But conditions are powerful language features, you say, and I totally agree. I think they should be used for the dual purpose of (1) dispatching commands (switch/case) and (2) eliminating/refining inputs. That is, you should always return in an `if` branch.
- shwestrick 6y ago> you should always return in an 'if' branch Interesting. This code style simply doesn't need 'else' at all. I can surely say, if I was reading a codebase that adhered to this discipline, it would be very easy to read. What are your thoughts on how difficult it is to write code in this style?
- yawboakye 6y agoSee http://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ http://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-val....
- rualca 6y ago> That is, you should always return in an `if` branch. I've had seasoned team members criticizing that approach as possibly the worst mistakes a developer can do. Their rationale is that you needlessly increase the cyclomatic complexity of a module whenever you return early, and if you care about logging you'll already have to add multiple code paths just to emit them.