4 Bad Coding Habits to Eliminate From Your Routine

We all have working methods and coding practices that suit us, but it’s easy to pick up a variety of bad habits when first learning to code.

And though coding is often incredibly collaborative, it’s very common for team members to refrain from looking too closely at one another’s content. When you spend all day every day glaring at your screen, the last thing you want to do is read more code. And what happens if you spot an issue? It isn’t generally fun to confront someone over something like that.

As such, it’s important for every coder to maintain a commitment to self-improvement. You can’t rely on others to point out your basic mistakes, so you need to get rid of them yourself. Let’s take a look at four bad coding habits you should eliminate from your routine.

Reusing Code Without Understanding It

There isn’t always value in doing everything from scratch. You’re not typically working to demonstrate your ground-up coding prowess, instead being tasked with achieving specific goals—and quite often you may find that you can reuse or rework an existing chunk of code from a library (or a forum post) to achieve in minutes what would have taken you hours or even days to manage by yourself.

This is totally fine, but it becomes a problem when you’re not absolutely sure what the code you’re repurposing is doing. It isn’t just a matter of whether it works or not, there are many more potential complications, including the following:

• Not knowing which parts of a large piece of code are necessary, if you include the entire thing, it can cause significant bloating.
• The solution may actually be extremely inefficient and could easily be improved but goes unnoticed.
• The method used invites a range of security vulnerabilities, which could compromise the integrity of an entire system.

If you find a piece of code that seems to do what you need done, or you have such a piece of code recommended to you, by all means consider it—just review it carefully before implementing it. By the time you actually use it, you should have a strong understanding of how it works.

Using Weak Names for Variables and Functions

Even if they prefer writing from scratch, the average coder is unlikely to spend all that much time doing so, because they’ll generally be adding to existing systems, adapting old code, or assembling modules alongside other coders. That means they’ll spend a lot of time reading through code they didn’t write, trying to understand it so they can start altering it—and the longer that process takes, the slower they’ll be able to work.

Imagine that you’re creating a JavaScript function for an ecommerce store to calculate the average value of a customer order. Ideally, you should call it something like calculateAverageOrderValue(), because that’s something that the average reader will readily understand. Just one glance should let them know what purpose the function is supposed to serve.

But you’re not obliged to use that sort of name, so there’s nothing stopping you from calling that function abc(). And if you’re in the habit of using random strings or even just letters to name your variables and functions, stop it. You’re not only making life harder for anyone who has to parse your code, but you’re also making it fairly likely that you’ll end up confused if you need to return to that code in a few months.

Being Inconsistent with Conventions

Coding conventions are important for parsing code quickly and accurately, and they can differ from person to person, but each coder needs to find an approach and stick with it. Think about how two books can feature two different fictional universes, but each one must have internal consistency to make any sense.

When a developer casually switches between using tabs and spaces when indenting lines or uses camelCase for naming things in one section but swaps to lowercase with underscores for the next, it runs the risk of causing needless confusion—and it can make the code a headache to look (and search) through. What if someone extrapolates from one section to search the entire file, but later discovers that they had the wrong case because you mixed up your style?

And if you don’t think this really matters, then think about resale value. Software is sold, plugins are sold, apps are sold—even selling your business directly is an option in a time of so-called website flipping. If your work comes across as amateurish when someone arranges a detailed review of your code, it might not matter how solid your work is from a technical standpoint. This isn’t about the ongoing dispute between those favoring tabs and those favoring spaces, or even the eternal war between Mac and PC users, because you should use whichever you prefer. Just pick one and stick with it.

Duplicating Code Unnecessarily

You may not always write code that’s stylish and elegant, and that kind of hyper-polished standard may not always be expected, so you don’t need to be self-conscious about coming up with a solution that seems somewhat pieced together. If it works well, that’s probably enough. However, there are some standards that you should always meet, typically involving code economy.

Suppose that you have a fairly-generic chunk of code that outputs an error message to the console when called, and though you wrote it for a single instance, you later realize that there are numerous places in which it needs to be implemented—so you take that chunk of code and paste it into every one of those places.

That may work, of course. But what happens when you want to tweak the parameters of that error-generation process? Yes, you guessed it: you need to track down and change every single instance of the code. This is precisely what functions are for. If you define the code as a function, you can then call it wherever it’s needed, and if you need to update it, you need only alter the function definition.

Is this a really obvious thing to understand? Yes. But it’s also something people may get wrong all too frequently. So, learn from those needless mistakes, and make sure that you’re being economical with your code.

Wrapping up, it’s absolutely fine to have a personal coding style, but mind that you don’t allow yourself to pick up bad habits while you work. If you tend to zone out while you write code, try spending a day being more keenly aware of the underlying mechanisms of your routine—you might just find that you’re a little sloppier than you thought!

REQ1911668 2/2023