4 Bad Coding Habits to Eliminate From Your Routine

Everyone goes through a slightly different education journey to become a developer, and while this is good in the sense that people have distinct learning preferences and can establish working methods that suit them, it’s also likely to produce a variety of bad habits—habits that you might have right now, without realizing it.

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 4 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’re going to 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 even a matter of whether it works or not, because there are many more potential complications, including the following:

  • Not knowing which parts of a large piece of code are necessary, you include the entire thing and cause significant bloating.
  • The solution is actually extremely inefficient and could easily be improved but you don’t notice because you never look closely enough.
  • The method used invites a range of security vulnerabilities, majorly compromising 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 you even think about 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 very 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, and the more annoyed they’ll be.

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 quite sloppy with your coding, you might be in the habit of using random strings or even just letters to name your variables and functions. If so, 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 makes 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 direct 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 stick with it.

Duplicating Code Unnecessarily

You can’t always write code that’s stylish and elegant, and no one expects that kind of hyper-polished standard, so you don’t need to be self-conscious about coming up with a solution that seems somewhat janky. 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 will work, of course. That much is true. 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 get wrong all too frequently (for whatever reason). 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!

This guest post was written by Patrick Foster, a writer and ecommerce expert from Ecommerce Tips, a leading online retail blog full of actionable advice for digital entrepreneurs. Be sure to stop by, and follow along on Twitter @myecommercetips.

Interested in how you can jump-start your career as a new developer? Download our course packet for more information about our Full Stack programs!

Download Course Packet

 

Author
Guest Blogger

Guest Bloggers for DigitalCrafts