Every Programmer Should Read This Book

Clean Code — A Handbook of Agile Software Craftsmanship

Recently I have read the book Clean Code and came to know about many good practices for Software Development.

I highly recommend you to read this book once.

The following are good pointers that I received from that book :

• Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.
• It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!
• Single Responsibility Principle: It states that every module or class should have responsibility for a single part of the functionality provided by the software and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. Robert C. Martin(Author of the book) expresses the principle as

A class should have only one reason to change.

• Say what you mean. Mean what you say: Your function name should follow this rule.
• Open Closed Principle: In object-oriented programming, the open/closed principle states that the software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification, that is, such an entity can allow its behavior to be extended without modifying its source code.
• Use Descriptive Names: Remember Ward’s principle: “You know you are working on clean code when each routine turns out to be pretty much what you expected.” Half the battle to achieving that principle is choosing good names for small functions that do one thing. The smaller and more focused a function is, the easier it is to choose a descriptive name.
• DRY(Don’t Repeat Yourself): The duplication is a problem because it bloats the code and will require four-fold modification when the algorithm needs to be changed. It is also a four-fold opportunity for an error of omission. Duplication may be the root of all evil in software. Many principles and practices have been created for the purpose of controlling or eliminating it.
• Writing software is like any other kind of writing: When you write a paper or an article, you get your thoughts down first, then you massage it until it reads well. The first draft might be clumsy and disorganized, so you wordsmith it and restructure it and refine it until it reads the way you want it to read.
• Use Exceptions Rather Than Return Codes: The problem with Return-Code approaches is that they clutter the caller. The caller must check for errors immediately after the call. Unfortunately, it’s easy to forget. For this reason, it is better to throw an exception when you encounter an error. The calling code is cleaner. Its logic is not obscured by error handling.
• Always Provide Context with Exceptions: Each exception that you throw should provide enough context to determine the source and location of an error. In Java, you can get a stack trace from an exception; however, a stack trace can’t tell you the intent of the operation that failed. Create informative error messages and pass them along with your exceptions. Mention the operation that failed and the type of failure. If you are logging in your application, pass along enough information to be able to log the error in your catch.

Again I must say that this book is really awesome for developers. These things are not easy to do, but we can do.

Happy Coding :)

Thanks

Amit Shekhar
Co-Founder @ Outcome School

Clap, share if you like it and follow me for the updates.