Understanding your own code
Translation of an article by Eli Benderski - Understanding your own code.
Recently, I was faced with a statement that puzzled me greatly. One programmer proudly stated that he could not understand the slightest piece of code he had written a week ago. I honestly tried to understand where this pride came from, but I could not. He was proud to write so much code every day? Who is ready to pay him for simply writing the code?
Let me clarify a little my opinion on this: the inability to understand code written a week ago or a year ago is absolutely unacceptable for a professional programmer. Since I said it, then let me explain. My serious programming experience is about 15 years. And at some point (quite early), I mastered some of the practices that I use to this day. I still can easily understand the code that I wrote a year ago, two years ago and even twelve years ago. Code written in various languages ​​and covering different areas. Algorithms, parsers, Web applications, embedded controllers, scripts, linkers, and much more. Even if I look at an earlier code that is more difficult for me to understand, I can still recognize the manifestation of some common features.
The main practice for achieving this result is the understanding that the code should be readable. Readable for you - readable for others. Unreadable code is as bad as code that does not work. And if you cannot understand your own code after some time, then there is no chance that someone else will ever be able to understand it. And this is not what it would be proud of.
')
I can't tell you how important it is to be able to read and understand your own code without much effort. Not only because it makes your product so much easier for others to support. But also because your code is your personal tool that you will reuse throughout your career. The presence of such a tool extremely expands the possibilities and is one of the distinguishing features of the programmer experience. I can’t even count the cases when my problems were solved instantly, as soon as I recalled that I had already encountered a similar problem in the past, dug up my own code archives and found a solution, or something close to it. Obviously, code that you do not understand cannot become part of such a tool.
It would be wrong to complete this post without even trying to explain how such a feat could be achieved. Honestly, it is not so easy to describe in words, but I still try.
I am sure that the same trick is used by writers (and, probably, representatives of other creative professions). Immediately after writing a piece of code (the smaller, the better), you should stop and evaluate its readability and legibility. Read and reread it several times. Try to move away from understanding the problem, imagining that someone is reading this code without the useful context that you already have in your head, because you are writing this code. Will this person understand what is written? If not, why not? Feel free to use “readable code” tricks from books such as “Code Complete” until you are sure that the code is clear.
And as soon as you are satisfied with the result, re-read it again. And again in a few days. This process reminds me of writing deeper scientific articles for this blog. First I write the text, then I re-read twenty sentences and rewrite five of them. Often this is true for the code that I write. Perfection can be either presented to you through genes, or through ruthless practice and repetition. So, as I was not gifted with the previous one, I adhere to the latter.
Finally, fearlessly refactor and improve the code. If you encounter a piece of code that could be clearer, then rewrite it more clearly. Improving the quality of the code is one of the subtle side problems of our profession. This is something that can often not be quantified, but after taking part in multi-year mega projects with a large team, understanding this will come to you unconsciously.
Recently, I was faced with a statement that puzzled me greatly. One programmer proudly stated that he could not understand the slightest piece of code he had written a week ago. I honestly tried to understand where this pride came from, but I could not. He was proud to write so much code every day? Who is ready to pay him for simply writing the code?
Let me clarify a little my opinion on this: the inability to understand code written a week ago or a year ago is absolutely unacceptable for a professional programmer. Since I said it, then let me explain. My serious programming experience is about 15 years. And at some point (quite early), I mastered some of the practices that I use to this day. I still can easily understand the code that I wrote a year ago, two years ago and even twelve years ago. Code written in various languages ​​and covering different areas. Algorithms, parsers, Web applications, embedded controllers, scripts, linkers, and much more. Even if I look at an earlier code that is more difficult for me to understand, I can still recognize the manifestation of some common features.
The main practice for achieving this result is the understanding that the code should be readable. Readable for you - readable for others. Unreadable code is as bad as code that does not work. And if you cannot understand your own code after some time, then there is no chance that someone else will ever be able to understand it. And this is not what it would be proud of.
')
I can't tell you how important it is to be able to read and understand your own code without much effort. Not only because it makes your product so much easier for others to support. But also because your code is your personal tool that you will reuse throughout your career. The presence of such a tool extremely expands the possibilities and is one of the distinguishing features of the programmer experience. I can’t even count the cases when my problems were solved instantly, as soon as I recalled that I had already encountered a similar problem in the past, dug up my own code archives and found a solution, or something close to it. Obviously, code that you do not understand cannot become part of such a tool.
It would be wrong to complete this post without even trying to explain how such a feat could be achieved. Honestly, it is not so easy to describe in words, but I still try.
I am sure that the same trick is used by writers (and, probably, representatives of other creative professions). Immediately after writing a piece of code (the smaller, the better), you should stop and evaluate its readability and legibility. Read and reread it several times. Try to move away from understanding the problem, imagining that someone is reading this code without the useful context that you already have in your head, because you are writing this code. Will this person understand what is written? If not, why not? Feel free to use “readable code” tricks from books such as “Code Complete” until you are sure that the code is clear.
And as soon as you are satisfied with the result, re-read it again. And again in a few days. This process reminds me of writing deeper scientific articles for this blog. First I write the text, then I re-read twenty sentences and rewrite five of them. Often this is true for the code that I write. Perfection can be either presented to you through genes, or through ruthless practice and repetition. So, as I was not gifted with the previous one, I adhere to the latter.
Finally, fearlessly refactor and improve the code. If you encounter a piece of code that could be clearer, then rewrite it more clearly. Improving the quality of the code is one of the subtle side problems of our profession. This is something that can often not be quantified, but after taking part in multi-year mega projects with a large team, understanding this will come to you unconsciously.
Source: https://habr.com/ru/post/233501/
All Articles