Your Most Common Coding Mistakes and How To Fix Them

Your Most Common Coding Mistakes and How To Fix Them

Programming is an art and science... nay, a skill that matures over time, weathered by good fortune, intuition, sheer luck and an insane of hard work. And, like anything, the only way to hone and refine that skill is to keep writing code, messing up and learning from mistakes.

In this situation, learning indicates an innate awareness of what you're doing, (the technical know-how); a realization of not only the process but the outcome. And, being able to see your mistakes, to acknowledge them and not be so in love with your code that you blindly accept it for perfection when it's flawed.

There are many mistakes that I have made in my journey with development and I want to share them with you. Rest assured, these common coding mistakes are not only limited to new coders and university students just learning how to code. Anyone of any level of coding proficiency is likely to mess up this bad, even on the best day.

So here are some of the most common programming mistakes made by developers and how to avoid them.


1. Improper or No comments

Can you imagine a program without comments? Just imagine how difficult it would be to read someone else's code without comments. The reason why we as developers miss out on comments is because when we write code, we are so engrossed in developing logic that we forget this essential step. I recommend that let you develop with the flow of logic that you have and plug in comments after you finish coding. Write comments for any and all complicated logic and SQL queries. Comments will help you a long way in reviewing your code.

2. Not reviewing your code

Once you get that good feeling looking at your code after you have completed it, it's best to review your code immediately and try finding issues if any. You should not only review your logic but also your SQL queries. Look for instances where you have executed SELECT/UPDATE/DELETE without a WHERE clause. For logic that is complicated you should dry run that piece of code to test if it works well.

3. Assuming Business Logic

What do we all do when we have no one from the business side to help us with Business Logic... we assume. Being proactive is good, but it could cost the client his business if you assume business logic. In situation like these its best to escalate your issues and concerns along with your assumptions to the business side and seek clarifications.

4. Not refactoring code

A silly question to ask, but here it is. How many times have our clients asked to take our sweet time to deliver a code? Well, never for me. So what do we do as developers? Develop code at the speed of thought, which results in the code being completely messed up and duplication of functions being created. I recommend that once you are done with your project and before the phase of QA begins, spend some time to refactor your code and optimize it as much as possible. This will ensure that your code is stable, reliable and reusable.

5. Not unit testing your code

Completing your code and getting ready for integration is the good part, but not unit testing your code bounces back on you when you start getting a series of integration errors. Its always better to unit test your code before you move ahead with SIT (System Integration Testing). Test functions and code separately to check if it works as desired with a range of parameters and try to automate it. Automating your unit tests will help you to execute tests whenever you make changes to your code.

6. Not maintaining list of changes

Not every developer is blessed with a code repository, though it is best to have it. In development environments where code repositories don't exist it's important to maintain a list of changes done on the project. Changes to files, configurations, databases, images, environment settings, etc are all important pieces of information that will be required at the time of deploying to staging or production environments and its a must to record these changes in a text file. Without such a text file you can imagine the outcome of deploying to production environments and missing some changes.

7. Not indenting your code

Indenting your code is very important, its ultimately you who will maintain it later. Indenting code not only helps you to structure your code better but also helps you to read and debug your code better. You should try and get a code beautifier that will help you indent all your code as per the rules defined, thus saving you time on bigger projects.

8. Not modularizing code

Not breaking the functionality into multiple modules/functions is a big crime. Break your code into as little form as possible to complete one logical set of functionality. Your function should do what it is intended to do, nothing more - nothing less. As a rule of thumb your code per function should not exceed one page of your screen. Exceptions to this rule do exist, but keeping this rule in mind from the very beginning of development will ensure that your code as modularized to a great extent.

9. Hard coding messages and configurations

Its bad to hard code messages and configuration parameters. This effects the flexibility to change the behavior of the application at runtime. With scripting languages like PHP it is easy to make such runtime changes. But for applications developed in Java or .NET that are compiled and deployed, it is a daunting task that can take as much as 30 - 40 minutes for deployment.

10. Not optimizing queries

I have been guilty of this too. We as developers think that writing the best code and using the most optimum function provided by the API is the only thing to do. But, we don't realize that the time taken to execute the script is entirely dependent on how sooner your database can serve results. Therefore, I recommend that you check all your queries with the query optimizer tool that comes along with most of the database engines.

11. Not comparing files

You should always compare the modified files with the original source base. This gives you an addition opportunity to review the code and changes done and if it confirms to business logic. Configuration and function files should always be compared to see and validate the changes that have been made.

12. Not having a backup of files before upload

Without a source control software it becomes important to that you backup important files before you upload changes. Such files should include but not limited to - configuration, database and important function files.

Being negligent is only one part of the security issue, but being negligent and not knowing it or not taking corrective steps later can also be quite damaging to your code.