Recognize the code must be easy to read

I recently encountered a big deal puzzled. A http://www.aliyun.com/zixun/aggregation/31.html "programmer proudly claims he can not read any code he wrote a week ago. Want to prove where he came from this pride, but no solution.He is so proud to write so much code every day? Someone would be willing to hire such people to write programs?

First, let me clearly state my point of view on this issue: I can not understand the code I wrote a week ago or a year ago. It is unforgivable to a professional programmer.

I'll put it aside. Now, let me talk in detail. I have been cautious programming for 15 years. Very early I accepted some programming habits, has not changed. I can easily understand the code I wrote a year ago, even 2 years ago, 12 years ago. Various language code, in a variety of business areas. Algorithms, parsers, web applications, embedded controllers, scripts, links, all you can think of. Even though there are some very early code that is difficult to understand, I can still see the shadow of some patterns.

The main way I can do this is to recognize that the code must be readable. Easy to read, easy to read by others. If the code is unreadable, it will be as bad or even worse than the code that is not available. If after some time you do not understand the code you wrote yourself, it is even more impossible for others to understand it. There is no such possibility. No software product will be proud of you.

I can not emphasize with a bigger voice, so easy to understand code is how important it is. Not only does it make your software products better and easier to maintain, but it will also become your own personal toolkit that you will use in future careers and use them repeatedly. With such a toolbox, you will become super powerful, which will be one of the important features that distinguishes you from other programming masters. I have not been able to remember how many times. When faced with some deja vu problems, I search through my history code base to find or reorganize the solution to the problem easily and quickly. Obviously, you can not understand the code can not enter such a toolbox.

It may seem a bit cynical to end this article, and I should explain how to practice that skill. To be honest, this is hard to describe in words, but I try my best.

I'm pretty confident that my approach is also being used by writers (and anyone who is engaged in innovative careers). Once you have finished writing a piece of code (the smaller the better), you need to stop to see if it's readable and understandable. Read it, read it over and over again. Out of your familiar environment on this issue, imagine those who have no idea of ​​the context at all reading this code. Can such a person read? If not, what is the point? Find out all the tricks you can from your "code-readability" treasure chest, made from books such as Code Encyclopedia, apply them until You are convinced that this code becomes legible.

Once you are satisfied, read it again. Read it again in a few days. This reminds me when I write some advanced technical articles, every sentence, I have to read on the 20 times, rewritten 5 times. This is often the case when I write code. Perfect can be made of natural, but also through relentless repetition and experiment. Because I do not have the former, I have always insisted on the latter.

Finally, reconstruction, fearless improvement. If you encounter a clearer code, let it be clearer. Improving the quality of your code is an additional task that is difficult to grasp in our profession, but when you meet a large project that lasts for one or two years and involves many people, you naturally realize that it's important.