What's the worst coding practices you have seen(or done!)?

No Offence, each one of us must have either seen or (mostly) done/followed some Coding Practices that we are not so proud of 😆.

Let's be honest here and post what are those. It would be great to see those with some examples, if possible!

To start with me, so far most horrible coding practice I had in two places:

  • Loops : I have written for loops that are nested to 4 levels with iterate variable named as, i, j, k, l etc.. When I look back, damm 😬!
  • Logical Conditions: &&, ||, ! with if-else. I have really done blunders in past where I wrote some if-else along with && and || that finally sounded very illogical and had to re-factor.

As Programmers, everyday is a new day with a new learning. I have learned too from my horrible programming practice mistakes. Still learning!

Let us know yours. 😄

Comments (22)

Add a comment
Sandeep Panda's photo

Good question and several useful answers so far! Here are some of the bad practices I have encountered:

  • Mixing early return with if-else
if (x) {
  return 1;
}
else {
  // Do something else
}
  • Inconsistent naming e.g. variable name looks like a boolean, but you store something else
var isPublication = "publicationId";
  • Making code harder to read and complicating it unnecessarily
return (x === 1 ? true : false);
  • Lover of callbacks e.g. nesting too many callbacks when you can easily avoid them using something like async/await
dosomething(10, 12, (data) => {
  doSomethingElse(data, (something) => {
    doAnotherThing(something, () => {
      // More callbacks
    });
  });
});
  • Making typos and copying the typos everywhere because you couldn't notice. Sometimes you misspell a variable name and copy-paste it to different places -- it works -- However, when other collaborators glance over the variable name and try to use it in some section, the code simply doesn't work. It wastes a lot of time because we are not able to figure out that the original variable name is incorrect.

  • Failing to return early by mistake. Some developers accidentally skip return keyword while returning early in case of error.

if (err) {
  res.status(400).end(); // This doesn't halt the execution of code
}

// rest of the code

There are many more, but these are the ones I've come across most frequently. I have always highlighted them in the code reviews so far. :D

Show all replies
Levi A Kirkland's photo

Any time I see code similar to below. The code author wraps a try/catch around a bit of code that should be written to ensure no failure, and the doesn't even write anything in the catch to overcome the issue. I feel this is the equivalent to On Error Resume Next . try { int i = (convert a string) } catch (Exception ex){}

//keep going....

Emil Moe's photo

My teacher! Not only was it in Danish, it was also ridiculous. Here is the (english) translated version:

/**
 * Determine kids gender.
 */
public isBoy() {
  if (this.isBoy) {
    return true;
  }
  else {
    return false;
  }
}

I also had another teacher who started out, when he for the first time showed us his code, by saying "this is a little messed and now how you should do it" – he had put all 5-10 classes of the application in the same single file.

Ehsan Fazeli's photo

I wrote a module couple of months ago that was the literal meaning of overhead.

We have a support center and it's running by a handful of trusted, experienced supporters that work with our platform and resolve the issues created by customers. The task was pretty straightforward, disable the skip button for one hour when an operator skips more than three issues.

What I did was to create an entity to store logs of when an operator has exceeded their skip threshold, cache the prohibition timestamp, create a job on queue and set its delay to one hour, create a worker to listen to the queue, create an endpoint to respond to the client current timestamp of the server, a boolean containing that he/she is prohibited or not, the future timestamp that their penalty would be dismissed and an interval that evaluates every single second to increment the time retrieved from server and compare it to the threshold to inform the user whenever they can skip the issues again.

All of which could be done with a simple local storage variable containing these simple info to handle it completely on client-side. I'm wondering why the hell I chose the first approach. Maybe I was bored at work at the moment. :D

Caleb H.'s photo

Mine was a security issue.

When I first got into backend programming, one of the first things I did was build my own authentication system (sign up, sign in, etc.)

And...I stored those passwords in plaintext. Yep.

But I learned from it later on, and now all my apps use hashes with salt to store the passwords.

It turns out Facebook had the same problem when it was first created...

...and they had one password that could be used by Facebook employees to sign in to any account. Yikes.

Quick tip: If you ever go to a website's "forgot password" page, and they email you your password, that website has terrible security.

Show all replies
Caleb H.'s photo

Co-founder of High/Low

😬 I feel your pain. Although at least it wasn't -rf?

Mohd Shad Mirza's photo

I'm a React Native Developer so my answer will be in that context.

  1. Global Variables: I used to define at the very start of my career.
  2. Arrow functions inside render method: For the first 4 months, I think. Then I had to implement a FlatList and optimizing it taught me a lot about rerendering.
  3. Inline CSS: It's a good practice to define a StyleSheet outside the render method because it keeps taking memory on every rerender.
  4. I used to write code with proper indentation and format then I enabled format code each save setting in VS Code and it's so much productive now.
  5. Using for loops: Can't say it's a bad practice but using Array Higher-Order Functions like map and reduce is so much efficient and code is more readable too.
  6. Using recursive functions everywhere: When I first learned Recursive, I started using it everywhere which is bad. If the stack is going to be large then it will take a huge amount of memory and you might run into stack overflow. It's important to know when to iterate and when to use recursion. Yup, that's pretty much it.
Tapas Adhikary's photo

Solution Analyst | Blogger | Dreamer | Manager

With given use cases, moving to map, reduce, filter etc from for-loops are so much fun to write and relaxing to read! Fully agree with you..