Checklist for writing good code
Following is a basic checklist every developer must tick off for a piece of code, no matter if few lines or hundreds of lines.
|Unit tests written|
|Consistent with the rest of the code|
- Readable – Always keep in mind your code will be used, fixed, debugged long after you have written it. So make sure it’s well commented(why you did it vs what are you doing), aim for self documenting code by picking good names for variable, function, classes and so on. Write all the assumption you have made. I read somewhere, code should be written so that it can be read like a book.
- Maintainable – No matter how perfect you have written your code and you are confident that it will never break. It will!!!!. Requirements change, design changes, there is a corner case you never thought off. So no matter what make sure your code is easily maintainable by you or others. No magic numbers, no hard coded strings, low coupling among modules, highly cohesiveness within a module. Changing one line of code shouldn’t have cascade of chain reactions. Keep it simple, people will thank you.
- Debuggable – Always assume things will go wrong in production environments where you won’t have the luxury to add more print statements or to attach a debugger or customer will not let you enter into their environments or problem may not appear again in next few years (but if it caused an outage, you have to fix it). All you will have is whatever your code emitted when the problem occurred. Always create well defined logs which give enough context for someone who is trying to debug the problem. Also keep in mind, generally there are lots of different components which generates logs at the same time. So lot’s of the time logs will be interleaved. So each logs must be complete on it’s own.
E.g. one log
“Problem occurred while contacting ‘xyz’, name resolution failed”
vs two logs
“Problem occurred while contacting ‘xyz’”
…..100s of logs from other components……
“Name resolution failed”.
Imagine how much time will be saved with the first log line.
- Unit tests written – Cheapest way to find bug as early as possible. Aim for as much statement coverage as possible. It’s an investment which will pay off in long run. Write it, write it and write it without exception.
- Code reviewed – Always get your code reviewed by someone (who takes it seriously). I have worked at places where code reviews are mandatory and where they are seemed as burden. You can imagine where I did I find the best written code.
- Consistent with rest of the code – No matter how strong is your opinion about variable/function names, tab spaces, always be consistent with the rest of the code. See the whole code for a product as a one big book, I’m sure you don’t want to read a book where one chapter is written in one font and other in different.
- Error handling – Never ignore errors, never. Always do error handling upfront instead of writing for successful cases first and handling errors later.
If you are just starting your “developer” journey, two must read books-