Three rules for good programming
Recently, I have seen a few really good code, a lot of mediocre and a lot of bad. (A lot of what I wrote before - especially when I first started - refers to the latter, alas.) Reading random online articles and professional books, I came to the conclusion that writing good code is easy. Incredibly difficult, but at the same time easy. In fact, it is so simple that it comes down to three rules.
By keeping them constantly, you will write good code. In any programming language and in any paradigm. The problem is that it is very difficult. All of them require discipline, and for the latter two, in most cases, long reflections are also needed.
This is the most important of the three rules that underlies the other two. Write a code that is simple for a person; leave the hard work to the computer. Use meaningful variable and method names. Do not create confusing logical chains where you can apply simple ones. Do not try to fit in one line as much as possible. Follow the single style of writing code that has meaningful indents. If your files are so bulky that it becomes difficult to scroll through them, break them up into several small ones.
Many programmers are trying to write what they think is faster, reduces the size of the application - in a word, “facilitates” the computer. This is great, but do not forget that it is much more important to write code that will be easy to read and support other people.
')
Your compiler (or interpreter) can handle completely different styles of code. For him, n and numberOfObjects are the same thing. For people, no. They will take a long time to read the code, even if the purpose of the variable seems obvious to you.
Imagine that you made a little script for yourself, and after a few years it took you a little to change it. What would you prefer to see: a well-structured script, with comments and a clear name, or one function without a single comment and with variables whose purpose is almost impossible to understand?
If you are doing something that is not obvious, in order to optimize part of the code, describe in the commentary what exactly it does. But do not forget that in most cases you will not be able to optimize the program better than the compiler. The reality is that he is smarter than you. It is a fact: compilers have been improving over the decades of hard work by professionals. There are exceptions, but they only confirm the rule.
Write code that people can understand.
I cannot count how many times the same code fragment has been encountered in different parts of the program. Just today I was working on a large function in obsolete code and saw the same conditions in two different parts of a conditional expression. I had to spend time trying to make sure that it was just a programmer’s mistake.
When you repeat the same piece in several places, you will have to return to it sooner or later to correct any mistake or add something new. This makes it difficult to maintain code. Instead of repeating yourself, place the fragment in a separate class or function that can be accessed as soon as it is needed. If you call multiple methods in different places in the same order, wrap it in a separate function.
Think about it that it will be easier to understand when you are familiar with the code: a fragment of 30 lines, freeing a block of memory, or a call to the clearMapVariableMemory () function?
You may need to examine the fragment later, but even in this case it will be easier to work with a separate function.
The same principle can be applied to data. If you often use the same variables, transfer them to a separate class or data type.
If you follow this rule, all changes will be universal - you do not have to recycle dozens of places to make a small amendment.
Do not repeat yourself.
The last rule is based on the previous two: each piece of your code should perform only one task. It is true at all levels: for expressions, functions and methods, classes and objects.
A few years ago, one developer showed me a broken code snippet. In order to understand it, the programmer took several hours. As a result, the problem was discovered in post-incremental C operators (in special cases, their behavior varies from compiler to compiler). Subsequently, reading one book on development, I noted that the real problem lies not in the operators, but in the fact that one fragment was responsible for performing many different tasks.
As I recall, the string containing the error was part of the ternary operation . That, in turn, performed several operations on pointers to calculate the condition, and several more, depending on the result of the conditional expression. It was a good example of writing code primarily for a machine, and not for a person: no one, except the author of the fragment, understands what a line is doing, even after reading it several times. If the programmer who wrote the code broke the logic into several parts, it would take much less time to solve the problem.
It is not necessary to extract, process and modify data in the same method. A verbal description of each function should be placed in one sentence. The purpose of each line should be clear. This makes the code understandable to people. None of us can store in our head a function that is several thousand lines long. There is no substantial reason to create such functions instead of several small methods used together.
It should be noted that this is not so difficult: to perform one large task, it is only necessary to divide it into several smaller ones, each of which is in a separate function. It is important to ensure that the purpose of each function remains clear, otherwise the code becomes too confusing.
Each piece of your code should perform one task.
Writing good code is hard work. I have been programming for four years - not so long, but quite enough to see quite a lot of problems, including mine. It became clear to us that we are complicating the development by not following these simple rules. Observing them correctly is difficult: it’s not always obvious where a separate class or method is needed. This is a skill. It takes a lot of time to become a good programmer. But if we do not follow these rules, writing and maintaining the code will become even more difficult.
Translation of Good Programming in 3 Simple Rules .
- Write code for people, not machines.
- Do not repeat yourself.
- Each piece of code should perform one task.
By keeping them constantly, you will write good code. In any programming language and in any paradigm. The problem is that it is very difficult. All of them require discipline, and for the latter two, in most cases, long reflections are also needed.
Write code for people, not machines
This is the most important of the three rules that underlies the other two. Write a code that is simple for a person; leave the hard work to the computer. Use meaningful variable and method names. Do not create confusing logical chains where you can apply simple ones. Do not try to fit in one line as much as possible. Follow the single style of writing code that has meaningful indents. If your files are so bulky that it becomes difficult to scroll through them, break them up into several small ones.
Many programmers are trying to write what they think is faster, reduces the size of the application - in a word, “facilitates” the computer. This is great, but do not forget that it is much more important to write code that will be easy to read and support other people.
')
Your compiler (or interpreter) can handle completely different styles of code. For him, n and numberOfObjects are the same thing. For people, no. They will take a long time to read the code, even if the purpose of the variable seems obvious to you.
Imagine that you made a little script for yourself, and after a few years it took you a little to change it. What would you prefer to see: a well-structured script, with comments and a clear name, or one function without a single comment and with variables whose purpose is almost impossible to understand?
If you are doing something that is not obvious, in order to optimize part of the code, describe in the commentary what exactly it does. But do not forget that in most cases you will not be able to optimize the program better than the compiler. The reality is that he is smarter than you. It is a fact: compilers have been improving over the decades of hard work by professionals. There are exceptions, but they only confirm the rule.
Write code that people can understand.
Do not repeat yourself
I cannot count how many times the same code fragment has been encountered in different parts of the program. Just today I was working on a large function in obsolete code and saw the same conditions in two different parts of a conditional expression. I had to spend time trying to make sure that it was just a programmer’s mistake.
When you repeat the same piece in several places, you will have to return to it sooner or later to correct any mistake or add something new. This makes it difficult to maintain code. Instead of repeating yourself, place the fragment in a separate class or function that can be accessed as soon as it is needed. If you call multiple methods in different places in the same order, wrap it in a separate function.
Think about it that it will be easier to understand when you are familiar with the code: a fragment of 30 lines, freeing a block of memory, or a call to the clearMapVariableMemory () function?
You may need to examine the fragment later, but even in this case it will be easier to work with a separate function.
The same principle can be applied to data. If you often use the same variables, transfer them to a separate class or data type.
If you follow this rule, all changes will be universal - you do not have to recycle dozens of places to make a small amendment.
Do not repeat yourself.
Each piece of code must perform one task.
The last rule is based on the previous two: each piece of your code should perform only one task. It is true at all levels: for expressions, functions and methods, classes and objects.
A few years ago, one developer showed me a broken code snippet. In order to understand it, the programmer took several hours. As a result, the problem was discovered in post-incremental C operators (in special cases, their behavior varies from compiler to compiler). Subsequently, reading one book on development, I noted that the real problem lies not in the operators, but in the fact that one fragment was responsible for performing many different tasks.
As I recall, the string containing the error was part of the ternary operation . That, in turn, performed several operations on pointers to calculate the condition, and several more, depending on the result of the conditional expression. It was a good example of writing code primarily for a machine, and not for a person: no one, except the author of the fragment, understands what a line is doing, even after reading it several times. If the programmer who wrote the code broke the logic into several parts, it would take much less time to solve the problem.
It is not necessary to extract, process and modify data in the same method. A verbal description of each function should be placed in one sentence. The purpose of each line should be clear. This makes the code understandable to people. None of us can store in our head a function that is several thousand lines long. There is no substantial reason to create such functions instead of several small methods used together.
It should be noted that this is not so difficult: to perform one large task, it is only necessary to divide it into several smaller ones, each of which is in a separate function. It is important to ensure that the purpose of each function remains clear, otherwise the code becomes too confusing.
Each piece of your code should perform one task.
Conclusion
Writing good code is hard work. I have been programming for four years - not so long, but quite enough to see quite a lot of problems, including mine. It became clear to us that we are complicating the development by not following these simple rules. Observing them correctly is difficult: it’s not always obvious where a separate class or method is needed. This is a skill. It takes a lot of time to become a good programmer. But if we do not follow these rules, writing and maintaining the code will become even more difficult.
Translation of Good Programming in 3 Simple Rules .
Source: https://habr.com/ru/post/191426/
All Articles