Rule Number 0
Do not write the damn code in the first place.
Rule Number 1
Use a code repository and implement version control. More projects have been delayed by laptops crashing than any other reason!
Rule Number 2
Use virtual environments. This will avoid library clashes and save many nights of labour!
Rule Number 3
Write Object Oriented code wherever possible; Makes life easy for everyone.
Rule Number 4
Avoid importing everything from a package – this pollutes the global namespace and can cause clashes.
Rule Number 5
Do not alter sys.path, use distutils for that.
Rule Number 6
Use descriptive variable and function names. You are not charged extra per character, and vowels do not cost extra!
Rule Number 7
Do not squish your code as tight as possible. Use spaces to increase readability, newlines to group small logical blocks
Rule Number 8
Do not mix tabs and spaces for indentation. Always use tabs, period!!
Rule Number 9
Exit early to avoid waterfall code. Especially for longer code blocks, this minimizes cognitive overhead.
Rule Number 10
Use defaults to avoid un-necessary else clauses
Rule Number 11
Use a sensible window size (<100x50 max) as a guide to refactor code:
- If your code does not fit into < pages, you likely cannot keep it into your head – refactor
- If your code is indented such that wraps, you are in too deep – refactor
Rule Number 12
Using < 4 space indentation is cheating and makes your code too dense to read easily.
Rule Number 13
Declare all variables at function start; that way, you can use introduction of a new variable as a hint to create a subroutine. Similarly declare variables only in the scope they are needed.
Rule Number 14
Allocate and release resources within the same indentation level / scope to avoid e.g. , memory leaks, use-after-free etc.
Rule Number 15
Do not repeat the same or almost the same code; abstract the difference and create a function / class.
Rule Number 16
Comments should explain why you are doing something, not what you are doing – your code should be readable by itself.
Rule Number 17
Be able to explain your code. There is a lot of code snippets out on the internet. Do not copy without understanding.
Rule Number 18
Write boring code.
print foo.join(map(lambda x: str(f(x)), g(y)))
looks cool but has a lot of cognitive overhead!
Rule Number 19
Do not use arbitrary limits and magic numbers. Define meaningful constants with commentary explaining the chosen value.
Rule Number 20
Check the return value of every function that may fail and yes that includes malloc(3)
Rule Number 21
Handle I/O in chunks; do not try to read all data into a single buffer. Somebody will give you input larger than you can handle.
Rule Number 22
Assume hostile input and usage. Always validate all input from outside your program. perl –T is a great option that I miss in python.
Rule Number 23
Do not shell out. Use exec (3) or similar. Things like popen(3) or system(3) can easily lead to arbitrary code execution via shell command injection. Parametrized execution of commands avoids that.
Rule Number 24
Do not assume you can write to current working directory. Do not assume that your program is run from any specific directory.
Rule Number 25
Ensure that your error messages are meaningful and include a useful diagnostic message preferably via stderror(errno), perror(3), err(3)…..
Rule Number 26
Avoid XXX and TODO – you will never go back and fix these
Rule Number 27
Be willing to rip off and throw away your code if you find an existing library or a better way.
Rule Number 28
There is value in understanding memory management and garbage collection in Python even though it is not required.
Do you know how python cleanses itself? | LinkedIn