5 Common Programming Mistakes to Avoid

Here, we will be discussing five programming mistakes that you can avoid to save yourself a lot of time and headaches. These mistakes apply to all programming languages and are very common among beginning programmers; especially among programmers who have taught themselves how to program, rather than get a degree in the subject.

  1. Jumping into projects without a proper plan

    • Intended Purpose – This is a mission statement, but specifically for your project. Short, sweet, and to the point. You don’t have to write an essay here, but a few lines describing what the purpose of this project is would be great. This is good for your potential investors, and your end-users to look at. It will also help keep you focused on what you wanted to achieve from the very beginning.
    • Features list – A features list is just going to be a specific list of features that you want to have in your projects.
    • An Outline – This will contain pseudo-code for your project. Think your code, written in plain English. Instead of writing functions, you write what the function is going to do and how you will be implementing it. This really helps when you’re going through the logical part of your coding. You can really clear a lot of things up here before you even have a single syntax of coding down. You can also use a flowchart to have an outline for your code, or do both.
    • A Project Summary – Make a quick summary of your pseudo-code. Yes, it seems a little redundant, but you don’t need to refer to that for every little thing, it’s more for when you’re actually programming. This part is also helpful if you’re trying to present your project to someone who may be providing funding; they have little interest in the logic of your code, but they sure want to know what the project is all about and how it will be unique.
    • This is a must for any business endeavor but even more so for programming because without this, you will be stumbling the whole way through your project if not just straight-up stuck in places. A proper Plan will include at the very least the following elements:
    • Not commenting your code
      • This is very common amongst beginning programmers who think that it’s pointless to add commenting to their code since they will be the only ones to touch the code. Well, I have news for you: 6 months from now, you will have NO idea what you were thinking at the time you wrote a particular piece of code and it may seem completely pointless without a brief comment above it explaining why it’s there. It’s always good to have long-term relationship with your code, even when you don’t think you will be updating it that often.
      • A lot of us who don’t learn programming through college education but rather from personal research forget that there are certain etiquettes taught when you go to colleges and commenting your code is at the top of the list. I remember when I took my first computer programming class, and my teacher was really anal about the formatting of the code and the commenting; even more than what the code did at the time. I didn’t quite understand the purpose at that time because the projects we did were so small in length that it seemed pointless, but boy did it make sense when I started doing my own projects that were a little lengthier.
      • For one thing, it will save you hours of trying to figure out why you implemented the code in a particular place, and for another it’s just proper coding etiquette. Any programmer who has in the industry for a few years will tell you that it is not only recommended to comment your code, but a must if you want to stick around in this industry.
    • Not formatting your code cleanly
      • Formatting your code in a readable and clean manner is just as important as commenting it. After all, what’s the point in commenting your code if everything is just a mess to read? You can make your life a lot easier by using a few indentations, and adding a few line-breaks between your functions. Comments, will even complement this because they will make it even easier to differentiate between functions when you put at least two line-breaks between the functions.
    • Not maintaining an update log for your project
      • Very often when you download, or install software on your computer, there’s a text file that comes with it and it tells you what changes have been made from the previous version. Well, it’s a good practice to do the same with your own projects because it will let you identify problems quickly and narrow down your search as to what time-frame of your code you need to look at in order to fix the problem. This follows similar logic to the commenting of code we talked about earlier, except this applies to version changes rather than specific lines of code.
    • Releasing the project without proper beta testing
      • Whenever we complete our projects, we are very anxious to release it to the users and sometimes a little too anxious because we release it commercially without proper beta testing. This can ruin your reputation as a programmer. You don’t want people to find all sorts of problems with your project AFTER a commercial release. You can do a few simple things to avoid this and keep your reputation intact.
      1. Find a diverse group of users to test your project – Seems logical, right? You’d be surprised how many people don’t do this and think just because they themselves have tested the projected from different platforms, it’s enough.
      2. Don’t limit your beta period to a set number of days. Good things take time, and if you spend the right amount of time here, it will save you a lot more time and resources when your project goes live. Set your time periods more like 2-4 weeks rather than exactly 18 days. 2-4 weeks, as an example, will let you test for at least 2 weeks, but extend another 2 weeks if you feel it’s necessary to get better testing done that way. It’s good to have that kind of flexibility.

    Guest Contributor

    This post was written by a guest contributor to Royal Tutorial. The author information is listed at the top of this post. To become a guest contributor, please visit our write for us page.