10 harmful programming habits for development projects [good article for a look], good article for development projects

10 harmful programming habits for development projects [good article for a look], good article for development projects

Parreto's law clearly states that 20% of results are caused by 80%. It is also known as the 80-20 rule. It applies to almost every field in which a person is needed as the labor subject.

In the field of software development, this rule can be summarized as that most problems are caused by a few bad coding habits. Changing these habits will make you more efficient.

The following describes the top 10 coding habits:

 

1. Spelling error

What makes me particularly surprised is that, even though everyone knows that this habit is harmful, it is still rampant in the Code, so that misspelled variable names and function names often occur. Even more tragic, misspelling is often well concealed and hard to find.

As for the solution, 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 select a specific variable name and function name. On the one hand, it is easy to spell, and on the other hand, it can be easily discovered even if it is wrong. Avoid using words that are easy to spell out, such as "receive", and easily spell them as "recieve ".

2. The code is not written in the specified format.

Indentation and formatting make our code clear and easy to understand, and provide a clear view of any errors. It is also easy for others to understand and maintain.

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

3. Code not modularized as required

A function corresponds to an instruction and is easy to understand and maintain because it is short. Long functions may have too many paths to implement, so testing is especially troublesome.

The first normative principle: A function can only occupy the space of one display screen at most. Second: if there are more than 10 if statements or loop statements, you can consider rewriting.

4. Over-reliance on IDE

There is no doubt that IDE and other tools can make your code write fast and well. Within a certain range, they provide variables and many other things, giving you a variety of choices for the content you want to input. However, this type of tool also has risks-if you cannot ensure that you have a bright eye, it is easy to mistakenly select a similar variable name. In essence, such tools replace part of human thinking, but in fact they are your responsibility.

Tools are indeed a good helper for us, such as eliminating spelling mistakes and improving work efficiency. However, if you are not careful about yourself, there will also be errors in code writing.

5. Use a hard-coded password

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

The reason is that hard-coded code is more vulnerable than you think, which makes it a huge security risk and a security risk that cannot be easily repaired.

6. No good encryption measures were taken to protect data

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

This also means that it is not recognized to send data in plain text, and also does not eliminate our own encryption methods and obfuscation targets. It is difficult to write a secure encryption system-you can see the wep situation-so we may wish to use a verified standard encryption library.

7. Premature code optimization

Donald Knuth, a legendary programmer, once said, "Programmers spend too much time thinking and worrying about the progress of programs that are not critical, these actions have a strong negative impact on efficiency. If debugging and maintenance need to be taken into account at the same time, the impact will be even worse."

Programmers who are good at writing code can indeed make the code run faster and smoother, but it will be difficult to debug and maintain it later. Provide a good strategy: After clearly writing the code, you can find a place that really needs optimization to improve performance.

8. No advanced thinking

What is the goal of the project? What is the expected scale? How many users are there and how fast are they running? At first glance, these questions seem to have nothing to do with our programmers-but if we don't think about them well, how can we choose to develop the application framework correctly to meet these requirements?

In this regard, Twitter has failed due to an underestimation of future requirements. As a result, it eventually had to abandon Ruby on Rails and rewrite a lot of code using Scala and other technologies, this is because the Ruby code originally used for architecture cannot keep up with Twitter's rapidly growing user base.

9. increase manpower to speed up the process

Almost all software projects will lag behind the plan. Some people may say that if the number of people is large and the number of people falls behind, can I keep up with the progress when I add people? It sounds pretty good, but the fact is that almost all projects have a "coagulation reaction" after adding "Fresh Blood"-the overall efficiency does not rise or fall.

10. Do not change the error message. Add an error to the error.

At, someone will say that since no human resources can be added, I will be able to catch up with the progress. I advise against such fantasies. If you lag far behind the scheduled time, it means that your estimated time for the project is wrong. Do not blindly stick to making mistakes, or make a new estimate of the project time.

10 Bad Coding Practices That Wreck Software Development Projects Author: codeceo-Xiaofeng