The Top 6 Most Frequent Coding Mistakes

Mistakes are the greatest teachers of all. They make us smarter, more efficient and more compassionate towards our fellow programmers. However, to learn from a mistake you have to first realise that it is one. This is why it’s important junior programmers and developers have somebody more experienced around to spot mistakes as soon as possible and avoid the same mistake recurring throughout code.

However, coders are busy people and code reviews can be shuffled to the bottom of the priority list. Therefore, you should always be looking to find mistakes in your own code—your team will love you for it.

“If you’re a junior programmer or developer who currently is lacking some guidance, one great option many aspiring coders are choosing, is working in a coworking space. Coworking spaces are a great way for programmers to network with experienced coders who are thoroughly self sufficient. Also, it’s a great way to be picked up by startups, small businesses and even large businesses who have migrated coworking spaces. If you want the full rundown on, read this article on the history of coworking.”

To make it easier for you, we’ve compiled this list of the most frequent coding mistakes.

Naming Variables Poorly

We have to name things all the time. It’s an underrated skill that we take for granted when we are easily making sense of someone else’s code. Being able to foresee how a variable name might be misinterpreted is a great skill to have.

Whenever naming a variable, ask yourself the following before you settle:

  • Does the name reveal the intention of that piece of code?
  • Is any part of the name you’ve picked ambiguous? Can it be misread?
  • Is the name too similar to another variable name? Can they be mistaken for each other?
  • Can people pronounce it? If multiple people were going to discuss this piece of code, are they likely to call it the same thing?
  • Is it searchable or will searching come up with a number of variable names?

One more thing, don’t use member prefixes. It’s not that they don’t work, it’s just that it’s a lot cleaner to not have them. They’re a bit archaic these days: most IDEs have the information available with a mouseover. Use and IDE and syntax highlighter so you can write your code in readable English and have the option of making it bold or italic.

Using Magic Numbers and String Literals

Magic numbers are numbers with unexplained meaning that need to be changed to constants. Magic numbers lack context, and that makes them meaningless. The number of what? Pizzas? Your team is not made of mind readers, so change magic numbers to a symbolic constant.

Take a look at the two following lines of code.

Magic number

bool setPassword = (length < 20);

Replaced with context

bool setPasswordAvailable = (length < MaximumPasswordLength);

Why 20? There’s an obvious answer, but leaving it to somebody else to figure out increases the risk of issues. “20” could have been anything, of course some of the other code gives us some context as to what 20 meant. But, when we replace it with “MaximumPasswordLength” it loses all ambiguity and the reader knows exactly what this piece of code’s purpose is.

Code that is full of magic numbers is error prone. Code that is given context tells all other developers what you’re looping and enables you and others to make changes more confidently.

Hard Coding

It’s hacky, inelegant and lazy.  Which is why you should do all you can to avoid it. Hard coding is essentially embedding things that shouldn’t be in source code into source code. Rather than obtaining data to embed from external sources, or generating data or formatting within the program itself.

Hard coding is bad practice because it cements code that should be flexible and assumes it’s unchanging. This encourages the use of magic numbers, which as we’ve already established, aren’t helping anyone. We usually hard code because it can solve the problem, and maybe this method might even be justified if it concerns passwords or file locations, but if you’re hard coding a lot, then you’re more than likely not exploring other solutions, which are highly likely to be better.

Giving a Function Multiple Responsibilities

“The single responsibility principle … states that every module, class or function should have responsibility over a single part of the functionality provided by a piece of software.”

The keyword here is “single.”

Functions should have a singular purpose and only have one reason to change. For example, imagine a function that both compiles and displays a report, we can see that the function has two responsibilities. One, the content of the report and two, the dimensions of the report. Why is this bad code design? Having two responsibilities in the same function makes your code less robust and more likely to break. The two responsibilities will change for different reasons, if one changes, the other is likely to break.

To keep your code more robust. Keep the single responsibility principle in mind. Write one function for each responsibility. The time you take to make more functions is faster than fixing broken ones.

Leaving Commented-Out Code

We’ve all seen it: a mysterious block of code, commented-out by a previous developer, with no apparent purpose. Did they mean to reimplement it and come back? Refactor it? If they wanted to delete it they would’ve just deleted it, right? But why is it still there?

Commented code is technically harmless to leave, but it does make things harder to read and is generally bad practice. If you can find the coder who put it there and ask them, you’ve wasted only a little bit of time; if you can’t find them, then you’ve just got to leave the mess there. Maybe they are using it as a point of reference while they are rewriting a piece of code, so they can review the differences. Other than this person, everyone else is unsure whether somebody needs it and therefore refrains from deleting it.

Whenever you’re working with others, I’d recommend you delete any commented-out code. If you need it or somebody else needs it, you can still access it in version control.

Poor Code Formatting

Junior programmers are always formatting code poorly, which is expected. Poor formatting is a reflection of a lack of experience, it’s the same reason why testers or data scientists are more likely to mess up formatting.

The easiest way to fix poorly formatted coding is by using a linter. Modern IDE’s will have functions that rearrange and reformat code to ensure clear formatting, as well as functions to exclude code which shouldn’t be reformatted.

If you’re an experienced programmer or project manager looking for work in Kolkata (India), Wellington (New Zealand), or Fort Wayne (Indiana), CodeClouds is always looking to hire great programming talent to add to their team. They provide upskilling, great benefits, and a good work culture.