12 Common Programming mistakes to Avoid Posted by Stranger on 9:13 AM Digg it Bookmark it Stumble it Email to friend

Programming is an art and science and like all art and science the only way to learn is from mistakes. I have made many… and I would like to share with you the mistakes that I have made over my journey with development.

These are some of the most common programming mistakes made by developers(including me) and how to avoid them (not listed in any specific order)
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 developersmiss 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 big ‘AAha’ 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 onlyreview your logic but also your SQL queries. Look for instances where you have executed SELECT/UPDATE/DELETE without a WHERE clause (not a joke… this happens). 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. Indevelopment 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 informaiton 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 developmentwill 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 behaviour 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 dependant 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.
Please feel free to share your programming experiences and write comments if you would like to share other mistakes not listed above so that developers like you and I can learn from it.