Home > Programming > 12 common programming mistakes to avoid

12 common programming mistakes to avoid

November 16th, 2007 admin Leave a comment Go to comments

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

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

Related Posts On Programming

  1. Recharge your Programming Batteries
  2. Ideas on Debugging your Live Website
  3. Why should every programmer upgrade knowledge
  4. 5 Tips on Improving programming Logic
  5. 6 Billionaire College Dropouts




Categories: Programming Tags:

Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /home/sunilb/www.sunilb.com/wp-content/plugins/all-in-one-seo-pack/aioseop.class.php:245) in /home/sunilb/www.sunilb.com/wp-content/plugins/mycaptcha/MyCaptcha.php on line 41

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/sunilb/www.sunilb.com/wp-content/plugins/all-in-one-seo-pack/aioseop.class.php:245) in /home/sunilb/www.sunilb.com/wp-content/plugins/mycaptcha/MyCaptcha.php on line 41
  1. Stephan
    November 17th, 2007 at 17:04 | #1

    Thanks for your summary!
    I totally agree with your statements. Especially unit testing is something I don’t want to miss nowadays as – if properly done – let us developers have a softer sleep at night. Hopefully many people will profit from them.

    Just a little remark: to me, it’s important to have knowledge of common design patterns to prevent making mistakes others have done while solving a particular problem. Furthermore, visualizing your work with uml and tools like doxygen is often very helpful for everyone who looks at your code with a fresh mind.

  2. November 18th, 2007 at 00:17 | #2

    This is a great post Sunil!

    I must admit that I am guilty of 1 and 3. I take great care in making sure that my code is well formatted and I use OOP for pretty much everything but I rarely comment my code. This is usually due to tight deadlines and my own stubberness. I don’t think it’s the end of the world since I use descriptive and consistent names for my objects, functions and variables and I do personally find that code with too much commenting makes the code itself hard to read and to see the big picture.

    #3 is one habit that im trying to break. I get up in my head sometimes and think that I know better than the client, so ill go ahead and use the Business logic that I think is best. Sometimes this works out and when it does the client is usually amazed, but when it doesn’t things can go bad and it results and a lot of unwanted revisions and back and forth emails.

  3. November 19th, 2007 at 10:22 | #3

    Great post, thanks for getting a good discussion started.

    IMHO, all you need is #5 and #12 and the rest takes care of itself. Starting with test first, virtually all the others either go away, resolve themselves, or become irrelevant.

    As to #1 I have to disagree with on principle and requires special call-out.

    This issue is sufficiently large enough it warranted its own post. Sunil, please check here:
    http://www.chadmyers.com/Blog/archive/2007/11/18/1-common-mistake-involving-code-commenting.aspx

    I’m curious to hear what you think about comments after reading that.

  4. Calvin
    November 19th, 2007 at 13:13 | #4

    I’m just wondering under which environments you think 6 would apply? I can’t really think of any reason why you wouldn’t have a repository. Local or remote.

  5. Andrés
    November 19th, 2007 at 20:49 | #5

    I agree with every point, I’m a bad programmer and still learning a lot. Thanks for the list!
    I only disagree with the “Programming is an art and science and like all art and science the only way to learn is from mistakes.”
    You should check out Art Brut and Dadá.
    I just love arts, when I’m loaded with too much code in my mind I start to paint. You should try that, it’s really pleasant. Or maybe you never get tired of programming… :P
    Chau!

  6. November 21st, 2007 at 09:17 | #6

    #1 I can easily imagine code with no comments. It is my goal to write code that doesn’t require them. When I think something needs a comment, I find a way to make the code say it instead.

    I just prepared a package of utility classes for publication to my peers. There may be one or two with more than a one line description at the top of what they do, but no more than that.

    I did prepare a nice “user guide” kind of thing in the package.html that gets built into the JavaDoc. The code speaks pretty well for itself but with 15 or 20 classes, it’s nice to have a roadmap.

  7. Abhay Bhave
    February 5th, 2008 at 19:51 | #7

    One ,ore thing to take care of, is I think using proper identifiers.

    Proper naming of data and methods that indicate their use very wel is very much important. Without this, you can’t understand line no. 159 of your code, especially if reading after 6 days! ;)

  8. February 25th, 2008 at 18:46 | #8

    About the 6th one – what you need to do is get a Version control system. Thats a must – programming without a VCS is like skydiving without a parachute.

  9. Vinayak Jadhav
    June 7th, 2008 at 03:18 | #9

    Hi Sunil,

    Its really gr8 to have website to share the programming knowledge in so descent way. The above points are really useful for me or any programmer. It will be greatful to me if we can chat or discuss the things.

  10. Arthur Ketcham
    August 10th, 2009 at 11:56 | #10

    Binny V A is right, programmers should always, always use a version control system to keep track of changes in code. It has the bonus as acting as a backup system to, if its something like Subversion. Using diff tools in combination with a version control system is extremely helpful. In a windows environment, I highly recommend WinMerge.

    If you don’t have access to a central, company VCS system (Subversion, CVS, etc.), use a distributed system installed on your local computer like Git or Mercurial

  11. December 12th, 2009 at 22:32 | #11

    This is a good list of programming mistakes to avoid.

    I would like to add that it is not necessary to add comments to your code. Comments should be added to function headers, file headers. But in code, comments should be added only when the code is complex and we need to explain why it is done. Other than that code should be self explanatory.

    Code reviews and refactoring should be done very often. Unit testing should be started along with development itself.

    During our busy schedule of software development, we tend to forget all this. But we need to keep reminding ourselves of the time and effort all this will save before project delivery.

  12. piyush kumar
    December 23rd, 2009 at 20:51 | #12

    Thanks for posting such a nice article …. but i have one question that does comments effects the server performance .. i mean if we use lots and lots of comments in one file then will it make server comparitively slower or not?

  13. January 13th, 2010 at 01:32 | #13

    Thanks.
    Really useful tips to consider

  1. November 17th, 2007 at 01:36 | #1
  2. November 17th, 2007 at 14:44 | #2
  3. November 17th, 2007 at 15:58 | #3
Enter this code to leave comment (Sorry, but bots get me crazy :) )