By Gerald Mücke | June 27, 2018
How to write good code
A couple of days ago I stumbled over a tweet on Twitter. It contained a list of catchy phrases what makes good writing. Developers also write, but more code than prose texts, so I wondered how applicable this list is to coding as well. So I came up with my own list, which might be a bit less catchy but is hopefully a usefully assembly of good coding practices or guiding principles.
The following list is taken from this tweet How to write good.
How to write good. pic.twitter.com/iJTaKZ6r5u— You Had One Job (@_youhadonejob1) 14. Juni 2018
These are the points on the list
- Avoid Alliteration. Always.
- Prepositions are not words to end sentences with.
- Avoid cliches like the plaque. They’re old hats.
- Comparisons are as bad as cliches.
- Be more or less specific.
- Writes should never generalize.
Seven: Be consistent.
- Don’t be redundant; don’t use more words than necessary; it’s highly superfluous
- Who needs rhetorical questions?
- Exaggeration is a billion times worse.
Although this is related to writing texts, parts of it are relevant to writing code as well.
Same rules, different context
For writing code or software in general, I re-interpreted the list. Although each point is a bit less catchy now, I hope it’s a good collection of good coding practices.
- Avoid baroque code, Keep It Short and Simple KISS
- Make control and data flows clear and concise. Handle alternative flows first (return/fail fast) and avoid exception handling for control flows. Write Light-bulb methods
- Write solutions to your particular problem and scale. Avoid Cargo Cult and Premature Optimization.
- Upfront thinking helps you identify concepts and patterns to make good abstractions but avoid Premature Abstractions. Don’t create an abstraction for less than 3 cases.
- Take care of proper naming of types, methods, variables and constants. Naming is part of the user experience for a developer and thus should be self-explanatory. “Don’t make me think!”
- Use the right data structures that suit best your use case. If you’re using a typed language, make good use of it and avoid too generic parameters or return values (Strings and Objects). No Generic and Unspecified Messages (GUM).
- Agree on and enforce coding rules to keep your code consistent. Coding is like Bowling, there are rule! “Smokey, this is not ‘Nam, there are rules!”
- Don’t do the same thing over and over again. Don’t be redundant. Don’t Repeat Yourself (DRY)
- Spend more effort on critical aspects and logic, keep those areas Clean, Concise, Correct and Checked (C4) and avoid bikeshedding.
- Don’t over-engineer things, You Ain’t Gonna Need It! (YAGNI)