Writing readable, maintainable and clean code has been my passion both as a developer and as a mentor guiding other fellow developers. With clean code, I have been able to throw so much garbage that I have actually reduced the lines of code that we have in the system significantly. This list is just a tip of iceberg in what you can do to make your code clean, but is a good start for those who seek to be better developers.
In now way I am imposing these as a standards. Situation could be different with different developers and organizations and the same rule of thumb might not apply for all.
Clean code features:
- Code should have a straightforward logic, no unnecessary twists and turns.
- No nests for bugs to hide. If you write a bad code, it’s a sweet home for the bugs to get born and grow.
- Code should have reduced or minimized dependency. Heavily dependent code is not clean, it’s a mess.
- Proper error handling strategy. Don’t let your code fail everywhere.
- Tuned for performance. No code is clean and good if it takes forever to run.
- Efficiency is the key.
- Leaves no broken windows (Dave Thomas and Andy Hunt). If you leave a bad code, chances are there will be more sprouts of bad codes.
- No Memory Leaks
- Consistent and meaningful Naming
- Clean code should do one thing and that one thing should be done well (Bjarne). Bad code tries to do too much stuffs at a time and leaves rooms for inefficiencies, maintenance horrors etc.
- Classes, functions or modules need to be unpolluted. They should contain only what is absolutely necessary. Don’t leave the unused variables, and objects around.
- Readability: Clean code should read like well written prose. There should be proper indentation etc. Huge list can go in this topic. But you might guessed what I am talking about.
- Understandability: The code should be easy to read and understand. Avoid the abbreviated variables, class names or methods.
- Should have proper unit tests. Code coverage matters. Although 100% code coverage is not practicable, the unit test code coverage should be as high as possible. But don’t focus on the coverage percentage, focus on what you are testing. Do not write test cases for just covering the code. Write the test cases that test the intent.
- All the unit tests that are written for the code should pass. Don’t leave the failing unit tests in your code.
- Should have proper acceptance test criteria.
- Any exposed interfaces and APIs must be clear and minimal
- Clean code should be easily maintainable by the non-original developers
- Clean code should be the code that has been taken care of (Michael Feathers)
- Should have reduced number of entities (objects, classes, methods, modules etc.)
- Should not have redundant logic scattered around the code.
- Should follow the Boy Scout Rule – ‘Leave the campground cleaner than you found it.’ This means, if you find a bad code around the classes and methods that you are writing, don’t curse the original author. Clean the code right away, so you have one less mess in your code.