I just finished reading a well written and instructive book on how professional software developers should code. The book is called ‘Clean Code’ and it was written by Robert C. Martin, also known as Uncle Bob.
For those of you who don’t know him, he’s an American Software engineer and he is best known for being one of the authors of the Agile Manifesto.
The book presents a well-structured viewpoint on how code should look like so that developers could read and maintain easily. To be honest, this book gave me a lot of knowledge on how to actually write good code.
Ok, so let’s start. Here is a summary of the main ideas and concepts I learn from each chapter of the Clean Code book:
Knowledge & Experience
Knowledge and experience are both important in writing clean code.
“There are two parts to learning craftsmanship: knowledge and work. You must gain the knowledge of principles, patterns, practices, and heuristics that a craftsman knows and you must also grind that knowledge into your fingers, eyes, and gut by working hard and practicing.”
Characteristics of a Clean Code: it should be elegant, efficient, pleasing to read, simple, without duplications, and well-written.
Choosing good names usually takes time but on long-term saves more than it takes. The name of classes, methods, and variables has to be meaningful and to clearly indicate what the method is supposed to do or what the variable is. The name should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent. Avoid disinformation by avoiding acronyms and confusing names.
Classes and objects should have noun or noun phrase names like Product, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb.
Methods should have verb or verb phrase names like postPayment, deletePage, or save. Accessors, mutators, and predicates should be named for their value and prefixed with get, set.
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Keep function under 30 lines of code. You should not scroll through the code.
Blocks and Indenting
Functions should not be large enough to hold nested structures. The indent level of a function should not be greater than one or two. It makes the function easier to read and understand.
Do one thing
Functions should do one thing and one thing only. Keep it simple. The reason we write functions is to decompose a larger concept.
Choose a descriptive name and don’t be afraid to make a name long. A long descriptive name is better than a short enigmatic name.
The ideal number of arguments is ZERO (niladic). Followed by one (monadic) and by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires special justification and shouldn’t be used anyway.
Comments are, at best, the necessary evil. The proper use of comments is to compensate for our failure to express ourselves in code. So, whenever you find yourself in a position where you need to write a comment, think and see whether there isn’t some way to turn the tables and express yourself in code.
Code formatting is important and should indicate things of importance since it is a developer of communication form. The code you deliver today has a good chance of changing in the next release. The coding style and readability sets precedents that continue to affect maintainability and extensibility long after the original code has been changed beyond recognition.
The Newspaper Metaphor The code should be written like a professional newspaper article. At the top, you expect a headline that will tell you what the story is about. As you continue, the level of details increases until you have all dates, names, quotes and so on. Try to write a class with a maximum of 500 lines.
We should keep our lines short.