5 Kinds of code comments that programmers should avoid

Absrtact: I recognize a very counterintuitive phenomenon, good programmers are lazy and silly. Because he is lazy, he will write all kinds of tools to work for himself. Because he is lazy, he will try to avoid writing boring and repetitive code--thus avoiding the redundancy of the code, reducing the cost of maintenance, so that the restructuring changes ...

I realize that a very counterintuitive phenomenon, good programmers are lazy and silly.

Because he is lazy, he will write all kinds of tools to work for himself. Because he is lazy, he will find a way to avoid writing boring and repetitive code--thus avoiding the redundancy of the code, reducing maintenance costs and making refactoring easy. Ultimately, the tools and best programming practices that have been developed due to the motivation of laziness have improved the quality of the product.

Lazy programmers have become good programmers. Of course, this is only part of the story; from a lazy programmer to a good programmer, he or she will show amazing laziness when learning how to be lazy forever-that is, what software tools make it easier to work, how to avoid it, and how to make it easier to maintain and refactor.

Secondly, (I will use a little more space to illustrate this point, because I find this view more difficult to accept than the first.) Good programmers are stupid. Why? Because if he's smart, or he knows he's smart, he'll:

A) Stop learning B) no longer high standards and requirements for your work

The 1th will lead him to stop trying to discover new technologies and make his work faster. The 2nd will cause his code to become difficult to debug and hard to refactor. In the endless war between programmers and compilers, it's a good idea for programmers to surrender at the start and admit it's their fault, not the compiler's fault (unless it's about character encoding, some compilers do).

However, there is a more important reason why a good programmer must be stupid. In order to find a better solution to the problem, he must keep a humble mind that he must jump out of the pattern to think about the problem. In a way, this will bring them back to the child's mindset, which is highly creative because they have never experienced the "no" blow.

The opposite mode of thinking is not so creative, it will be considered to be familiar with the status quo, will accept the status quo. But who knows how much you don't think is really impossible? The less you know, the more aggressive you will be. The better the tools you develop, the better your products will be because they become more high quality.

I conclude from my work that a good programmer, when he confirms a requirement from the manager, needs to think in a stupid way; he will ask the simplest, child-like question. He would not take the information provided by the provider of the question for granted. A typical conversation in web development would be this:

"Yesterday, a customer said that the logo image on our website could not be displayed. ”

"Did he restart the browser?"

Yes ”

"Did he restart the computer?"

Yes ”

"Did he empty the cache?"

Yes ”

"Is he using IE6?"

Yes ”

"Is he sure he didn't see it?"

Yes ”

"Is he looking at our website on the computer screen?"

"What?"

"Well, he might have printed it out. ”

"No, look is staring at the screen." ”

"Can he see other pictures on the site besides the logo?"

"Oh, I ask." ”

To illustrate our theme (the story is completely fictional), we assume that the customer really closed the browser's picture display. Maybe his son did it. Anyway, if you think in "smart" mode, it's hard to find the answer. So the problem that the programmer asks doesn't require any programming knowledge. Because this is a silly question, so only silly way to solve.

A few years ago, I had a long phone discussion about what broke the site because of one of my updates .... It turns out that the guy banned his browser's CSS. From then on, I began to doubt everything, not because of such a simple thing to listen to 1.5 hours what is the complaint of code quality. Finally, the guess is that my update is out of the question .... just a guess. If you want to solve the problem, the best way is to listen only to the facts, not to hear what they think might be the reason.

Similarly, when a colleague asked me: "Why is this not good for you?" Most of the time because they modify the wrong problem (for example, he wants to link lib1, but he actually links to Lib2, or in fact he does not link any lib at all). When you ask a colleague for help, especially programming problems, you don't usually tell him more about the project. When he asks silly questions, you subconsciously resist the answer, because you think you know it clearly, but in fact you're not.

Of course there is another side to it. Too stupid can not think of any way, do wrong, can not solve any problem. And too smart to sit and plan questions, but seldom act. Pragmatic programmers to take them. He knows that 10 decisions a mistake is better than just five correct decisions and five more times.

It's kind of like a story about a centipede. The centipede is good at walking with its 100 legs. It never thought how it could do that. Until one day, a bug asked him, "How do you control so many legs?" Don't you think it's hard for them to walk at a certain pace? When the bug was finished, the Centipede was still sitting there thinking, thinking about how to walk, wondering, and even (for the first time in this life) some worry. From that day on, the centipede was no longer able to take a step.

So, if you want to achieve something, don't think too much. Of course, it's just half the story ...

Recommended reading: 11 Words that programmers should know

Novice programmers must read: Seven Proverbs to drive programming

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

5 Kinds of code comments that programmers should avoid