August 15, 2014 at 18:08Understanding Native Code
Translated article by Eli Benderski - Understanding your own code.
Recently, I came across a statement that puzzled me a lot. One programmer proudly stated that he could not understand the slightest bit of code he had written a week ago. I honestly tried to understand where this pride comes from, but I couldn’t. Was he proud to write so much code every day? Who is willing to pay him to just write the code?
Let me clarify my opinion a bit about this: the inability to understand the code written a week ago or a year ago is absolutely unacceptable for a professional programmer. Since I said this, let me explain. My serious experience in programming has been around for 15 years. And at some point (rather early), I mastered some of the practices that I use to this day. I can still 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 various areas. Algorithms, parsers, Web applications, built-in controllers, scripts, linkers, and much more like that. Even if I look at earlier code, which is more difficult for me to understand, I can still recognize the manifestation of some common features.
The main practice for achieving such a result is understanding that the code must be readable. Readable for you - readable for others. Unreadable code is as bad as code that doesn't work. And if you can’t understand your own code after some time, then there is no chance that anyone else can ever understand it. And this is not at all something to be proud of.
I can’t convey how important it is to be able to read and understand my own code without much effort. Not only because it makes your product 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 greatly expands the possibilities and is one of the distinguishing features of the programming experience. I can’t even count cases when my problems were resolved instantly, as soon as I recalled that I had already encountered a similar problem in the past, I dug up the archives of my own code 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 end this post without even trying to explain how such a feat can be achieved. Honestly, it’s not so easy to describe in words, but I’ll try it anyway.
I am sure that writers (and probably representatives of other creative professions) use the same trick. Immediately after writing a piece of code (the less the better), you should stop and appreciate its readability and legibility. Read and re-read it several times. Try to step aside from understanding the problem by 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? Feel free to use the “readable code” tricks from books like “Code Complete” until you are sure that the code is clear.
And as soon as you are happy 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 re-read twenty sentences and re-write five of them. Often this is true for the code that I write. Perfection can be either given to you through genes, or through ruthless practice and repetition. So, as I was not gifted with the previous one, I stick to the latter.
Finally, fearlessly refactor and improve the code. If you come across 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 tasks of our profession. This is something that often cannot be quantified, but after participating in long-term mega projects with a large team, an understanding of this will come to you subconsciously.
Recently, I came across a statement that puzzled me a lot. One programmer proudly stated that he could not understand the slightest bit of code he had written a week ago. I honestly tried to understand where this pride comes from, but I couldn’t. Was he proud to write so much code every day? Who is willing to pay him to just write the code?
Let me clarify my opinion a bit about this: the inability to understand the code written a week ago or a year ago is absolutely unacceptable for a professional programmer. Since I said this, let me explain. My serious experience in programming has been around for 15 years. And at some point (rather early), I mastered some of the practices that I use to this day. I can still 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 various areas. Algorithms, parsers, Web applications, built-in controllers, scripts, linkers, and much more like that. Even if I look at earlier code, which is more difficult for me to understand, I can still recognize the manifestation of some common features.
The main practice for achieving such a result is understanding that the code must be readable. Readable for you - readable for others. Unreadable code is as bad as code that doesn't work. And if you can’t understand your own code after some time, then there is no chance that anyone else can ever understand it. And this is not at all something to be proud of.
I can’t convey how important it is to be able to read and understand my own code without much effort. Not only because it makes your product 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 greatly expands the possibilities and is one of the distinguishing features of the programming experience. I can’t even count cases when my problems were resolved instantly, as soon as I recalled that I had already encountered a similar problem in the past, I dug up the archives of my own code 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 end this post without even trying to explain how such a feat can be achieved. Honestly, it’s not so easy to describe in words, but I’ll try it anyway.
I am sure that writers (and probably representatives of other creative professions) use the same trick. Immediately after writing a piece of code (the less the better), you should stop and appreciate its readability and legibility. Read and re-read it several times. Try to step aside from understanding the problem by 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? Feel free to use the “readable code” tricks from books like “Code Complete” until you are sure that the code is clear.
And as soon as you are happy 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 re-read twenty sentences and re-write five of them. Often this is true for the code that I write. Perfection can be either given to you through genes, or through ruthless practice and repetition. So, as I was not gifted with the previous one, I stick to the latter.
Finally, fearlessly refactor and improve the code. If you come across 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 tasks of our profession. This is something that often cannot be quantified, but after participating in long-term mega projects with a large team, an understanding of this will come to you subconsciously.