Some common programming mistakes to avoid

Every developer learn from mistake including me – heh heh. So from my long working experience some common programming mistakes given below which developer must avoid:

1. 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 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.

2. 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.

3. 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.

4. 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.

5. 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 only review 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.

6. 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.

7. 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.

8. 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.

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.

Advertisements

One Response

  1. […] random neuron misfires wrote an interesting post today onHere’s a quick excerpt Every developer learn from mistake including me – heh heh. So from my long working experience some common programming mistakes given below which developer must avoid: 1. 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 […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: