The book describes the principles of organization and formatting of the source code of the program so that in the future it was easy to maintain such code. This book is like a bible for many programmers. The book is more than 400 pages and so many are sometimes lazy to read, and there is always not enough time. Therefore, we decided to highlight the most important points. We want to share with you the most interesting authors’ ideas!
The main paradox
Programmers face the basic paradox of core values. Every developer who has some significant experience knows that the previous mess slows down his work. But at the same time, all developers under pressure create a mess in their code to meet the schedule. In short, they don’t have time to work fast! Real professionals know that the second half of this paradox is wrong. It is impossible to keep the schedule, creating a mess. In fact, this mess will immediately slow down your work and the schedule will be disrupted. The only way to keep up with the schedule – and the only way to work fast – is to keep the code clean at all times.
Avoid fake information
Programmers should avoid false associations that obscure the meaning of the code. Do not use words with hidden meanings other than intended
Use pronounceable names
People are comfortable with words. A large part of our brain is specialized in the concept of words, and words are, by definition, pronounceable. It would be a shame not to use that hefty part of the brain that developed for colloquial speech. Therefore, the names should be normally pronounced.
Choose names that are easy to find
Single-letter names and numeric constants have one specific drawback: they are hard to find in a large amount of text.
Avoid name encoding schemes
We already have enough trouble with coding to look for new complexities. Encoding type or scope information in names only creates more deciphering hassle.
Compact!
First rule: functions should be compact. Second rule: functions should be even more compact. The length of the function shouldn’t exceed 20 lines.
Blocks and padding
It follows from the above that blocks in if, else, while, etc. commands should consist of one line, which usually contains a function call. Not only does this make the enclosing function more compact, but it also helps to document the code, since the function called in the block can be given a convenient meaningful name.
Single operation rule
A function should only perform one operation. She must perform well. And she doesn’t have to do anything else.
Reading code from top to bottom: downgrading rule
The code should read like a story – from top to bottom. Each function must be followed by functions of the next level of abstraction. This allows you to read the code by successively descending the levels of abstraction as you read the list of functions. I call this approach the ‘lowering rule’.
Another way to put it is that the program should be read as if it were a set of paragraphs, each of which describes the current level of abstraction and refers to subsequent paragraphs of the next lower level.
Switch commands
Writing a compact switch statement is quite difficult. Even a switch statement with just two conditions takes up more space than I imagine a single block or function should take up.
It was the first part of our article related to this book. Follow our updates to discover more!
