According to “Clean code” book by Robert C, he defined some guidances and rules that developers should follow. This is more imperative for the less experienced developers. With more experience, comes the possibility of breaking some rules or reinventing them with justifications.
No code comments.
A good code needs no comment. The variables, methods, and any other component of the code such as attributes should use easily identifiable and descriptive names.
“Code comments are smell, remove them.”
Dead comments or code should be deleted.
Any unused piece of code or comments should be deleted. The best place to find them is in the version control systems.
Incorrect behaviour at boundaries.
Boundaries should always be unit tested. No behaviour should be assumed.
Positive conditionals.
Positive conditionals are easier to read than negative conditionals.
Standard architecture, coding, and design guidelines should be followed.
All the set standard architecture, coding, and design guidelines should be adhered to. Tools should also be used to ensure that this is accurate.
Good and Consistent naming.
Try to call variables, methods, classes to be understandable from the caller perspective. And it should be consistent.
KISS principle should be applied.
Needless complexity should be avoided. With increase in complexity, some design and codes in the system become useless. All designs and codes should be kept as simple as possible.
Use of exceptions instead of return codes.
In exceptional cases, an exception should be thrown, when the method fails to do its intended purpose. Null or return codes shouldn’t be used.
Make things small. Class size and method size both matter.
Typically, method should be small and compact in size. Ideally, <100 lines of code.
Boy scout rule- Leave the campground cleaner than you found it.
Leave the campground cleaner than you found it. Don’t ask for permission to refactor the code.
Thank you for stopping by and see you in the next.
Top comments (2)
Great breakdown of clean code principles! I’m a big fan of Robert C. Martin’s Clean Code and appreciate how you’ve distilled these rules for both newbies and seasoned devs. A few thoughts:
One question: how do you balance “small methods” (<100 lines) with avoiding over-fragmentation? I’ve seen tiny methods sometimes obscure the bigger picture. Curious about your take!
Thanks for sharing—looking forward to your next post!
I extract code into smaller methods when they represent a logical step in a process, making the main method read like a high-level narrative. This helps with readability without excessive fragmentation.