10 programming habits that are harmful to your development projects

Avoiding these common coding habits will make our jobs easier and our software more secure and easier to extend.

The Pareto Principle clearly states that 20% of the causes lead to 80% of the results. Also known as the 80-20 rule, it applies to almost every field that requires people as the main labor force.

In software development, this rule can be summarized as: most problems are caused by a few bad coding habits. Change these habits and you will be more productive.

Here are the 10 worst coding habits:

[[121062]]

1. Spelling Errors

What is particularly surprising to me is why people still allow this habit to run rampant in their code, even though they know it is harmful and has no benefits, resulting in frequent misspellings of variable and function names. What is even more tragic is that misspellings are often well hidden and difficult to detect.

As for solutions, writing code in a good integrated development environment (IDE) or simply using a programmer-specific text editor can significantly reduce spelling errors. You can also choose specific variable and function names that are easy to spell and easy to spot even if you make a mistake. Try to avoid using words that are easy to misspell, such as "receive", which can easily be spelled as "recieve".

2. Failure to write code in the prescribed format

Indentation and formatting can make our code clear and easy to understand, and any errors can be seen at a glance. It is also convenient for others to understand and maintain.

If you are using an IDE that does not automatically format your code, consider using code beautification software such as Uncrustify, which allows users to customize formatting requirements and then it will enforce them meticulously.

3. Failure to modularize the code

The habit of one function corresponding to one instruction is quite good, because it is short and easy to understand and maintain. Long functions have too many possible paths to implement, so testing is particularly troublesome.

The first rule is: a function should occupy no more than one screen space. The second rule is: if there are more than 10 if statements or loop statements, then you should consider rewriting it.

4. Over-reliance on IDE

There is no doubt that IDEs and other tools can help you write code quickly and well. To a certain extent, they can provide variables and many other things, and give multiple choices of what you want to enter. But there are risks in this type of tool - if you can't ensure that you have a keen eye, it is easy to mistakenly select similar variable names. In essence, this type of tool replaces part of human thinking, but in fact it is your own responsibility.

Tools are indeed good helpers for us. For example, they can eliminate spelling errors and improve work efficiency. However, if you are not careful, you may also make mistakes in writing code.

5. Using hard-coded passwords

Many people tend to hard-code a secret account and password so that they can freely enter the system later. But this is wrong - yes, it is indeed very convenient for you, but it also makes it very convenient for others to access your source code.

The reason for this is that hard-coded code is more fragile than you think, which makes it a huge security risk, and a security risk that is difficult to fix.

6. Not using good encryption to protect data

Sensitive data needs to be encrypted when it is transmitted over the Internet, because it is very likely to be intercepted during the process. Don't complain about the trouble, this is the most basic security requirement.

This also means that sending data in clear text is not allowed, and it also rules out rolling our own encryption and obfuscation measures. Writing secure cryptographic systems is hard - just look at the case of wep - so we might as well use a tried and tested standard cryptographic library.

7. Optimizing code too early

Donald Knuth, a legendary programmer, once said, "Programmers spend too much time thinking and worrying about the progress of noncritical parts of their programs, and this has a strong negative impact on efficiency, especially if debugging and maintenance are also taken into account."

Programmers who are good at writing code can indeed make the code run faster and smoother, but later debugging and maintenance will become more difficult. Here is a good strategy: After writing the code clearly, find the areas that really need to be optimized to improve performance.

8. Not thinking ahead

What is the goal of the project? How big is the expected scale? How many users will there be and how fast will it run? At first glance, these questions seem to have nothing to do with us programmers - but if we don't think about these questions, how can we correctly choose the framework for developing applications to meet these requirements?

Twitter is an example of a company that failed because it underestimated future demand. As a result, it had to abandon Ruby on Rails and rewrite a lot of code using Scala and other technologies. This was because the Ruby code originally used for the architecture could not keep up with Twitter's rapidly growing user base.

9. Thinking that adding more people will speed up progress

Almost all software projects fall behind schedule. Some people would say that there is strength in numbers, and if I fall behind, can't I just add more people to catch up? It sounds good, but the fact is that almost all projects experience a "coagulation reaction" after adding "fresh blood" - the overall efficiency does not increase but decreases.

10. If you know you are wrong but don’t correct it, you will make more mistakes

Continuing from point 9 above, some people may say that since we cannot add more people, we can just rush to meet the deadline. I advise you not to have such illusions. If you are far behind schedule, it means that your estimate of the project time is wrong. Don't blindly insist on making the wrong decision. It is better to make a new estimate of the project time as soon as possible.

Translation link: http://www.codeceo.com/article/10-bad-coding-break-project.html

Original English text: 10 Bad Coding Practices That Wreck Software Development Projects

Translated by: Xiaofeng