10 behaviors that make you a bad programmer

Before this site published "excellent Programmer's 10 habits" and "programmers need to have the basic skills", that is what we need to learn and develop. Here, we mainly discuss the characteristics of 10 bad PHP programmers, mainly need to let us to avoid and careful. 1) Emotional thinking if you start to look at the world with a different color, you could be a bad programmer. Emotional thinking or attitude is likely to turn yourself into a monster. I believe you can often see a lot of bad programs using these statements: My program can't have this problem. Java is shit. What I hate most is designing with UML. How old the demand is, it's not done. Can't stand these people, they really understand AH. ...... ...... These emotional thoughts and attitudes can not only make you a bad programmer, but can even affect your future. Because, emotional is usually the devil, will let you make the wrong judgment and decision, error rate judgment and decision directly determine your life. 2) The process of doubting others ' bad things always says, "My code must be correct, I suspect the compiler has a problem," I should have no problem, how can STL libraries be so hard to use? I've seen programmers use STL classes like this: map , when he found that the string is not taken out, think that is the STL library bug, and then wrote a map! Oh my God! At some point, premature conclusion is a bad habit, and everything has its reasons, and only by knowing the reason can you know whose problem it is. Generally speaking, always make your own problems. 3) Too much attention to implementation, into the details of the problem sometimes, when we face a problem or a demand, bad programmers will always find a solution or implementation, this is a bad habit. Design patterns tell us that "liking interfaces, not implementations" is telling us that it is more important to recognize the nature and characteristics of a problem than how it is achieved. For a customer's problem, the first thing to think about is how to let the user work properly, if the recovery is "bleeding" system, rather than put the user aside to analyze the cause of the problem and solution. To solve a bug, reproduce the bug, understand the original program intent is the first important thing, rather than immediately to modify the code, or will inevitably introduce more bugs. For a requirement, we need to understand the requirements behind the business context, use case and real intent, rather than discuss if implemented. Only by understanding the user's real intentions, to achieve the use, you can really if you do design. Bad programs tend to get bogged down in detail, arguing about how to do it, the root cause of the problem, and ignoring something more important than that. Only when you understand the whole map, do you know how to go. 4) Use unfamiliar code bad programmers the best friends are ctrl-c and ctrl-v, and sometimes they don't know the exact meaning of the code and start using it, and there's evidence that the majority of bugs that are caused by copy-pasting are points. Because the code is always only in a specific environment in order to work properly, if the context of the code changes, it is likely to make the code to generate a lot of things you do not know, when you can't control the code, you can also create a good program? 5) work hard instead of smart work for bad programmers, we can always see them trying to fix their bugs, always spending a lot of time and doing a job repeatedly. A good program may take twice the time to prepare an effective development environment, tools, and spend double or even 10 times times the time of development to avoid some mistakes. Good programmers always use all the tools or means to make their work more efficient, and always try to be as error-prone as possible when developing. The cost of later mistakes will be huge, and the pressure to correct them is enormous. So, bad programs usually let themselves into a vicious circle, they always look tired, always very hard, so there is no time to improve, the less time to improve, there are more problems. So, working hard sometimes may indicate that you are not a good programmer. 6) always waiting, making excuses and complaining when demandWhen it is unclear, when the environment is not very satisfied, they are always waiting for the improvement of others. When there is a problem, always looking for excuses, or complaining that it is not good, it is not good, so I certainly did not do well. Bad programmers always want their environment to be the best, have a clear need, have a very good development environment, have enough time, have good QA, there are strong team leader, as well as considerate of their managers, enough training, have good discussions, have strong support from others ..., This is a kind of "mouth, clothing" attitude, the world is not perfect, a team needs everyone to struggle, moreover, if everything becomes perfect, then, what is your value? Driving instead of waiting, leading instead of following.7) breeding office politics there is a saying that "ugly women do more mischief," meaning that if one does not have the real ability, then he will be in other aspects of the article. Bad programmers do the same, and if they do poorly, they tend to rely on others to blame, to shirk responsibility, or to crowd out those who are capable, and so on, to preserve themselves. So bad programs are usually accompanied by office politics. 8) Programmers who do less bad often think they know everything, and they don't feel that their knowledge is limited. This is the so-called rhetoric, yes, what can not be done by a programmer what to do? It's just blowing and blowing. Another way to behave is that they are commenting on someone else's program or design, always picking up a bunch of bugs, but their programs are poorly written. Always criticize the complaint without any constructive advice or propose a workable solution. These bad programmers, always like to criticize other people's programs to achieve the display of their excellent. 9) Stubborn when you give a dozen proofs that there is a better plan there, there is a better way, they will always be stubborn to think their own approach is the best. One of my personal experiences is that when I see a new program in the wrong direction when it comes to solving a problem, I remind him that you may have gone the wrong way, that it was the other side, and I proved to show him that there is a simpler method. However, the programmer told me, "That is my method, I must go down, or I will be very uncomfortable," so, in the code review three days later, after a stubborn explanation and a doubt, he had to adopt the method I first told him. These programmers, never to think, nor to find people to discuss whether there is a better way, but to stick to their own ideas, it is even a dead end of a straight ahead, do not hit the south wall will never look back. 10) write "smart" code they write the code needs other colleagues to view the program Language Reference manual, or the program's logicOr style looks quite fashionable, but it's very difficult to read. The code should be concise and easy to read, and they like to show themselves in code, and try something different to show their talent. Yes, only programmers with the ability to have problems need to use such a display. Remember a previous experience, a very good English programmer to join the company, originally for US English DAO, we like to see is simple and easy to read English documents, then, the man to show his English how cattle, the use of a lot of gre more uncommon phrases and vocabulary. It's hard for everyone to read. Ironically, one of the Native Americans later asked him about the meaning of a word in his mail. Oh. Are you a bad programmer? Free to receive the Lamp Brothers and original PHP tutorial CD/"Detailed PHP" Essentials Edition, details of the website customer service: Http://www.lampbrother.netPHPCMS two times development http://yun.itxdl.cn/online/phpcms /index.php?u=5 Development of HTTP://YUN.ITXDL.CN/ONLINE/WEIXIN/INDEX.PHP?U=5 Mobile Internet server-side development http://yun.itxdl.cn/online/server/ Index.php?u=5javascript Course Http://yun.itxdl.cn/online/js/index.php?u=5CTO Training Camp http://yun.itxdl.cn/online/cto/ Index.php?u=5

