10 programming habits that are harmful to development projects

Avoiding these common coding habits makes our work easier, the software more secure and easier to scale.

Used clearly pointed out that 20% of the results resulted in 80%. Also known as the 80-20 Law, it is applicable to almost every person who needs to be the subject of labor related fields.

In the field of software development, this rule can be summed up, most of the problems are caused by a few bad coding habits. Change these habits and you will be more efficient.

10 programming habits that are harmful to development projects

Here are the most undesirable 10 coding habits:

1. Spelling errors

What makes me particularly surprised is why everyone knows that this habit is not a benefit, even if it is still allowed to wreak havoc in the code, so that often misspelled variable names and function names. More tragic

Is that the wrong spelling is often well concealed and difficult to spot.

As a workaround, you can write code on a good integrated development environment (IDE), or simply use a programmer-specific text editor, which can significantly reduce spelling errors. You can also choose Special

Variable names and function names are easy to spell on one hand and can be easily found on the other, even if they are wrongly written. Try to avoid words that are easily misspelled, such as "Receive," which can be easily spelled

"Recieve".

2. Do not write code in the prescribed format

Indentation and formatting make our code visible, easy to understand, and error-prone. It is also easy for others to understand and maintain.

If you are using an IDE that does not automatically format the code, then consider using code beautification software such as Uncrustify, which allows the user to customize the format requirements, and then it will meticulously

Perform.

3. Code is not coded as required

A function that corresponds to an instruction is quite good because it is short so it is easy to understand and maintain. Long functions can be implemented with too many paths, so it is particularly troublesome to test them.

The first specification principle: A function can occupy up to one display space. The second: if there are more than 10 if statements or loop statements, then you can consider rewriting.

4. Over-reliance on the IDE

There's no doubt that the IDE and some other tools can make your code fast and well-written. Within a certain range they can provide variables and many other things, giving you a variety of options for what you want to enter. But

There is also the risk of this type of tool-if you cannot guarantee that you have eyes, it is easy to choose a similar variable name by mistake. Essentially, such tools replace a part of the human mind, but

Actually, it's your own responsibility.

Tools are really good helpers, such as eliminating spelling mistakes and improving productivity, but if you're not careful, there's also the problem of writing the wrong code.

5. Using a hard-coded password

Many people tend to hardcode a secret account and password so that they can enter the system freely. But it's not right--yes, it's really a big convenience for you, but it's also

Big convenient for others to visit your source code.

The reason is that hard-coded code is more fragile than you think, which makes it a huge security risk, but also a very bad security risk.

6. No good encryption is taken to protect data

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

This also means that sending data in clear text is not recognized, but also excludes our use of our own encryption and confusion of target measures. It's hard to write a secure encryption system-look at the WEP situation

You know-so we might as well use the proven standard Crypto library.

7. Premature code optimization

Donald Knuth, a legendary programmer, once said, "programmers spend too much time thinking and worrying about the progress of the non-critical parts of the process, because these actions are more efficient

A strong negative impact, and if you also have to take into account the commissioning and maintenance, then the impact more. ”

Programmers who are good at writing code can actually make the code run faster and smoother, but later debugging and maintenance will turn out to be difficult. Provide a good strategy: After you have written the code clearly, then find the real need

Optimized to improve performance.

8. No thought of advance

What is the goal of the project? What is the expected size? How many users will be running faster? These questions seem to have nothing to do with our programmers at first glance--but if you don't think about it,

These questions, how can we correctly choose the framework to develop the application to meet these requirements?

Twitter, for example, has failed to underestimate future demand, causing it to eventually have to abandon Ruby on Rails and rewrite a lot of code that uses Scala and other technologies because

The original Ruby code for the architecture didn't keep up with Twitter's fast-growing user base.

9. Think that the increase in manpower can speed up progress

Almost all software projects fall behind schedule. Some people will say, the strength of the person is too strong, backward then I add the staff can not keep up with the progress? It sounds pretty, but the truth is, almost all the items

After adding "Fresh blood", "coagulation reaction" has occurred-the overall efficiency does not rise and fall.

10. Mistakes are not changed, the mistake is added wrong

Next to the 9th, some people will say, since can not add staff, then I am always able to catch up with the progress. I advise you not to embrace this illusion. If you are far behind schedule time, that means that you

The estimated time of the project is wrong. Do not blindly insist on will wrong, or early on the project time to make a new estimate it.

Link:http://www.codeceo.com/article/10-bad-coding-break-project.html
English original: Ten bad Coding practices that wreck software development Projects

10 programming habits that are harmful to development projects