By Richard 'Jodi' Maxwell 2018-04-05
-
You are a writer, not a programmer.
-
Your code is read by:
- People
- Tools
- Compiler
-
80 character lines are more readable in more tools than longer lines
-
Try to maintain context to one screen (25-80 lines)
-
If it's simple keep it simple
-
Don't make functions that are only used in one place
-
multiple lines are more easily diff-able than long single lines
-
Write code for what you need, do not write code for 'what if'
-
Do not generalise until you need more than 3
-
Track the flow of data and the code will show itself
-
Be aware of cache usage when designing data structures
-
Law of Demeter
-
Aim for functions to have no side effects
-
Use the same name for the same data across all your functions and arguments
-
Do not use "size": use "count" or "bytes" instead
-
use 'ijk' as loop indices, if you need more, you're doing it wrong
-
If your units are not type safe, then append the units to the variable name
-
Hungarian notation turns variable names into liars
-
Don't mix mutliple fixes into one checkin
-
Comments are liars
-
Comments should explain why
-
Comments should go under the code, not the side or on top
-
leave an empty line after a comment
-
leave an empty line before an if statement
-
Always put if statement blocks inside braces
-
Write code that uses your API before you write implementation
-
Treat API examples as production code, they will be copy and pasted
-
You API should have both simple and expert exntry points
-
Put API inside 'include' and implementation inside 'src'
-
APIs should be heavily commented
-
The day you stop learning is the day you start dying
This is my brain dump of tweetable advice for better programming. It is full of generalisations which can have valid exceptions, while other statements are more a reflection of my generaly asthetics. They shouldn't be taken as rules, but as items to make you question your own programming.