6 bad habits in programming you should avoid

I have developed some good habits after years of development experience. I also found some of the bad habits I will avoid. In this article, I show some of the bad habits I've observed in the development process. The discussion here is all my personal opinions. The so-called bad habits in this article may be good habits that other developers uphold.

Bad habits 1, rely on code formatting tools

Many programmers like to use code formatting tools to beautify their code. I usually disable the code formatting tool when I install a new IDE or code Editor such as Visual Studio. I'm doing this for a couple of reasons,

• Good programmers should have good habits. You might agree that it's a good habit to write well-styled code by hand, even though you think it's not a bad habit to use code formatting tools. So since all code is styled manually, the code formatting tool is not needed.
• The format produced by the formatting tool does not conform to my own code style. I had my own code style before the code formatting tool became popular. For example, when some editors format C++ code, there is a space between if and left parentheses, and my style has no space.
• For a powerful editor, I might be able to configure formatting tools to meet my needs, but that's a waste of a lot of time, and I'm going to repeat it again with a different editor. The more serious problem is that some editors cannot be configured to meet my needs.
• For any developer who is as senior as me, the habit of formatting code manually is as natural and efficient as breathing.
• The use of code formatting tools is a bad habit because there is also the downside that in team development, either everyone must use the same editor for the same set of code formatting rules, or it can cause a mess because some people use one code formatting tool and the others use another tool.

Bad habits 2, rely too much on the IDE

A good IDE(integrated development environment) and code Editor will undoubtedly increase productivity. I myself have some long-used and favorite IDEs, such as Visual Studio, Qt Creator, and Visual Studio Code. But if you're only used to some kind of IDE, and you almost can't work if you don't have the IDE, then it's a bad habit. Excessive reliance on the IDE can have the following problems,

• The IDE has done too much for you, so you don't understand many of the underlying mechanisms. For example, usually an IDE will create and manage project files for you, then you will not understand how the project and libraries are referenced, how the code files are dependent, or even you can not understand how the resource files are packaged into the executable file.
• For simple tasks, the IDE often reduces efficiency. For example, if I were to write a C++ program with 100~200 lines of code in a single source file, it would be more efficient for me to write a code file in NotePad++ and compile it with GCC in the command line than to create a project file in Visual Studio.
• The IDE is not always available. For example, when you join a new team, you may find that all team members are using Eclipse instead of Visual Studio to develop C++ projects. Your best bet should be to use Eclipse, which you are not familiar with, to ensure that you are at the same pace as your team, so that VS is not available to you.

We can enjoy the efficiency gains that the IDE brings, but we also need to develop habits that we can develop efficiently without the IDE.

Bad habits 3, rely too much on the debugger

You may be similar to me that we think Visual Studio or GDB debugger is powerful and convenient. But reducing reliance on the debugger will make our development more efficient,

• We should develop the habit of writing "error-free" code and avoid fixing bugs through the debugger. It is impossible to write code that is absolutely error-free, but we can develop good habits and coding styles to reduce the chance of errors. For example, using smart pointers correctly in C++ can greatly reduce the chance of memory leaks. If you're still explicitly using new and delete to manage memory, you should start using smart pointers to manage memory instead of relying on the debugger to troubleshoot memory leaks.

• In quite a few cases, the print statement is more efficient than the debugger. In fact, even when I have a debugger, I often use print statement for debugging.

• The debugger is not always available or is not always easy to use, so it is even more important to solve the problem without a debugger.

Bad habits 4, comment too much in the code

Countless companies, teams, so-called mentors and senior developers, as well as so-called code style guidelines, are working tirelessly to teach and require programmers to write comments and documents in their code. But when I see too many comments in the code, I just think it's a potential problem, not a norm that should be advocated,

• Good code should be self-explanatory. If you need to write a comment to illustrate what a function is for, you should choose a more appropriate function name and parameters name instead of writing a comment. Again, the code is read by human beings, not by the machine.
• Too many comments can significantly reduce the readability of your code. You can look at a lot of open source code library interface files, you need to look for code in a large number of document comments.
• Most of the time, comments will be more outdated than code. Such comments are of no use other than to reduce the readability of the code.

Note that I'm not against comments in the code, I'm just against using comments to replace the work of improving code readability. Comments should appear in the following places,

• Describe complex algorithms
• Reference to the source of the copied and pasted code
• Describe code that is too tricky (or called hack)
• Describe the temporary code

Bad habits 5, inconsistent code and programming style

This is perhaps the least controversial point. In a project and a team, no matter the existing programming style is good or bad, we should keep a consistent code style. If the project uses MFC style m_ as member variable prefix, then you should also use this style, even if you think the style is very outdated.

Bad habits 6, "work too hard"

You must have found the quotation marks on the title at the first sight. Hard work is no doubt a good thing, especially trying to create something unique and creative. But when you find that you are happy to do repetitive things, there is a problem, because the computer was invented from the first day to solve the repetitive work.

• When you repeatedly copy/paste and modify the code for the same logic, it's time to abstract the code into modules.
• When you solve the same kind of bug over and over again, it's time to review your design problems.
• When you do a tedious task over and over again, it's time to master a scripting language such as Python or Perl to automate these tasks.

Conclusion

After reading all the bad habits I have listed, perhaps you agree with certain points of view, and disagree some if not all. Never mind, these are inherently more subjective opinions.