Top 10 Clean Code Rules. According to “ Clean Code” Book by Uncle… by Ian Kiprono Stackademic

Top 10 Clean Code Rules. According to “Clean code” book by Uncle… | by Ian Kiprono | Stackademic #

Excerpt #

According to “Clean code” book by Uncle Bob, he defined some guidances and rules that developers should follow. This is more imperative for the less experienced developers. With more experience…

[

]( https://medium.com/@Ian_carson?source=post_page-----831fb34caff7--------------------------------)[

]( https://blog.stackademic.com/?source=post_page-----831fb34caff7--------------------------------)

According to “Clean code” book by Uncle Bob, 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.

For more information, please read the book. A more in-depth analysis is done by @ktiarad here.

Thank you for stopping by and see you in the next.

Stackademic #

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn, and YouTube.
• Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.