Bad coding practices no. 1: Turn naming into a riddle game

Let’s warm up with something easy. For a good start, add some extra abbreviations to your variable or function names. 

I know, I know – it’s good practice to make all the names as descriptive as possible, right? Like handleFormSubmit, getUserConfiguration or parseCustomerInformation. But we are not here to do a good job. 

For bad results, always shorten and abbreviate the names as much as possible, so the next developer working on your code will have to guess what you were thinking about. 

Names like handleBtnClick, getConfig or parseInfo are good casual examples. They don’t reveal too much what the functions are doing but you can still run with it during code reviews. And unnecessary abbreviations like btn, func, config or cb make it even harder to understand.

You can do so much more with variable names! Have a list of unconfirmed users? Don’t call it uncofirmedUsers, just named it users. The next developer will have to read the WHOLE code that returns the variable to understand what’s in it. No discountedProducts for that poor soul, because the product’s name is still true and enough.

To add a little spice to the names you can always play with the casing, and I guarantee the co-workers will hate your guts for that. Instead of creating eg.: a readXmlDocument as the good practices recommend (abbreviations should be formatted like regular words) you can make a readXMLDocument method that will require the other developers to look closely and read the name more carefully to fully understand it.

Of course, all of this madness can be stopped during a code review but your job is to fight for it. Maybe because you’re too lazy to fix it, or maybe because you need your troublemaker persona to maintain. One way or another, remember you can always promise to change it with the next pull request hoping everyone will forgive and forget your sin (and probably they’ll do).

Bad coding practices no. 2: Write very complicated code

Here you will have an opportunity to prove you’re a Rick Sanchez of software development. 

You just need to write your code in a bit more complicated way than it should be. 

Maybe you can find some generalisation that will allow you to reuse three lines of code in two places by creating a method that accepts five parameters? Maybe you can reduce three lines of code into one by using a clever triple nested ternary operator? Your imagination is the limit! 

Of course, it will make the application harder to read and maintain but that will probably be your coworkers’ problem, right? Excellent!

So give it a go and write a code that proves you’re a real hacker. I suggest you use chained functions, nested conditional statements, over-bloat design patterns and clever one-liners that use niche hipster features of the language you write in. Because why write Date.now() if you can do the same thing with a bit more cryptic +new Date()? I’m sure your colleagues from the project will thank you for it when they will spend time trying to understand what the heck is happening in the code.

And remember: the more the code is overengineered and early-optimised the more you will make your coworkers struggle with it. You get 10 respect points for using a reduce function and 100 points for making a recursion call. By the end of the project, that will make you a real pro coder, congrats! 

Bad coding practices no. 3: Import from everywhere

I understand that the aforementioned technique can be hard to push through code review. But if you’re a web developer writing in JS or PHP, you have many import/use clauses on the top of almost every file. A lot of developers don’t check it during code review because they scroll directly to, what they think, is the meaty part. 

That’s why the dependencies are a great place for you to invite horrors to make themselves comfortable in your code. 

Imagine you have some UserSubscriptions view in React. Create a file with a helper function calculateTimeToSubscriptionEnd. Great. Now where you should put this file? In a separate directory that stores all the domain logic related to subscriptions or payments? Pff, of course not. Better put it next to the view you just created! 

It’s thinking ahead because when you will finally make the admin panel (and the Subscriptions view there), nothing stops you from importing the helper function from the user views. And probably no one will notice it, because almost no one checks the imports list. This way you will couple two unrelated modules and make hell for developers who will ever try to change something or refactor the code. And trust me, nothing makes developers crazier than a terribly structured project. 

I hear you say, “This doesn’t look like a huge obstacle”. Less experienced developers may not fix this for a long time. They’ll struggle with the mess they’ve found, thinking it’s important to keep it as it is. It will hurt them EVERY SINGLE TIME when a new developer tries to understand the application structure. It will be even more triggering when the devs update or delete something related to that function. A little mess that hurts everyone until some hero will fix it. Maybe it can even be you someday?

Bad coding practices no. 4: Make the same functions behave differently

Do you consider yourself a creative, artistic soul? Here’s your new favourite torture method. 

The world is unpredictable and no one’s ever said that everything must work the same way. Also, no one ever said that consistency and predictability are the keys to a great developer experience or successful project. Well, many people proclaim that, but we don’t listen to them today, OK? 

We are here to ruin someone’s day is by making similar functions in the codebase behave a bit differently.

For example, you may have some validation functions that return true when the data is valid and the string with an error message when something is not quite right. What if the next validator your add will return false or undefined when the passed value is correct? That will break someone’s plans to write a very clean form handling. Good… 

You can also accept arguments of totally different shapes in every function. Like in the meme above. Let’s some of them accept the user ID but others the whole users object (even if they need the ID only). Or maybe you will find a way to accept the users’ emails? That will be a massive killjoy for the next developer that will have to work on that code.

I bet you can come with even better ways to surprise other developers, so why not make everything unpredictable. Drop consistency! Long live the randomness! Also, never think about the big picture of the project’s codebase, focus on adding a bit of fun to every single file separately. In other words: don’t be an engineer, be an artist! I guarantee you that other developers will hate that from the bottom of their hearts. But that’s obviously because you’re so ahead of your time.

Bad coding practices no. 5: Copy the code all over the place

Pull this off and no one will ever want to work with your code ever again. 

Don’t separate any common logic into different functions, classes or components. Just copy the lines your need between files. 

After all, your code is perfect and very important, so let’s make everyone see it multiple times throughout the whole project. Let it shine!

But you see, that’s not the only good reason for duplicating the code. In case of any updates, it will force developers to make changes in many files at once. What’s better, someone may (and probably will, if there are not enough tests in the project) miss one or more occurrences of the copied logic and will be forced to do a second or even third fix. And what is more fun than searching for the same code in hundred files of the project’s codebase? I bet your coworkers will love it.

Remember that making a good abstraction is hard and time-consuming so you should always skip doing it and copy the code where it’s needed. Your code reviewer will understand this. If not, then you can spend the time you saved explaining why it’s important to make more copies of your precious code. You can do it, I believe in you!

Satan is calling, so I’m wrapping up 

This article is obviously a joke. Don’t do the things I described above. For real, it’s not a “hold my beer” bet.  

Just do everything the other way around:

• keep naming in your code descriptive and clear, 
• make your code simple and understandable to everybody,
• maintain a clean project structure, 
• never forget to write consistent and predictable interfaces, 
• separate common logic whenever it’s possible without losing the code clarity. 

Oh, and never be mean to your colleagues. EVER!

There’s a saying in the development community that you should always write your code like the next developer that comes after you is a serial killer. You don’t want a killer to hate you, do you? I don’t like this attitude. 

I think you should always write your code like the next person working on it is… yourself. 

Next time you’re actively coding, just ask yourself: “Would I be happy seeing those lines after I’ve long forgotten what they do”?