Terrible coding examples

Caporegime
Joined
18 Oct 2002
Posts
32,623
We recently got some software from a partner to take over nd fix up. they were in charge of writing it but it kept crashing and seemed to have endless problems. It is is full of beautiful gems like this:


Code:
 public UInt64 shift(int i)
                {
                        if (i ==0)
                                return (1 << 0);
                        else if (i == 1)
                                return (1 << 1);
                        else if (i == 2)
                                return (1 << 2);
                        else if (i == 3)
                                return (1 << 3);
                        else if (i == 4)
                                return (1 << 4);
                        else if (i == 5)
                                return (1 << 5);
                        else if (i == 6)
                                return (1 << 6);
                        else if (i == 7)
                                return (1 << 7);
                        else if (i == 8)
                                return (1 << 8);
                        else if (i == 9)
                                return (1 << 9);
                        else if (i == 10)
                                return (1 << 10);
                        else if (i == 11)
                                return (1 << 11);
                        else if (i == 12)
                                return (1 << 12);
                        else if (i == 13)
                                return (1 << 13);
                        else if (i == 14)
                                return (1 << 14);
                        else if (i == 15)
                                return (1 << 15);
                        else if (i == 16)
                                return (1 << 16);

                        return 0;
                }


not that its broken, but why, just why!


Any examples of madness you have seen?
 
Caporegime
OP
Joined
18 Oct 2002
Posts
32,623
It depends how open your company is to refactoring code. There are places where once you finish a "feature" / "bug fix" and get it tested and signed off, management are reluctant to go back in and refactor even though you have some nasty code that will most likely cause you loads of trouble down the line.

I need to find a new job ...

With us it is more of a question of time, if code works then we wont sped time refactoring it because there will be some over fire to fight and deadline looming. It is a start-up so we are always struggling to finish work as it is, e.g. last week I got given an emergency task to help a customer Thursday at 5pm that had to be working on Monday 8am. So our code is often not fantastic but, there is no excuse for terrible programming like I put in the OP. Why would you even thing of doing it that way, and where on that list of IF statements would you realize the stupidity, and once it was all done why would you not just delete and start again to avoid the embarrassment?

It is not only that it is wasteful and slow, there is a good chance if making an error somewhere in that block and you shift by the wrong value and never notice it without staring at the code.
 
Caporegime
OP
Joined
18 Oct 2002
Posts
32,623
My favourite is short but silly:

Code:
return count(foo) == 0 ? true : false;

or

Code:
if (count(foo) == 0) {
   return true;
}
else {
   return false;
}

What an absolute waste of space!


Almost forgivable but completely pointless.
I've seen far worse though!

Code:
class  Foo {
  bool stupid;
  ...
}


class Bar {
  Foo foo; 
  ...
  bool isStupid() {
     if (foo.stupid == true) {
         return true;
      } else {
        return false;  
     }
}

Bows my mind people can code like that and still have a job!
 
Caporegime
OP
Joined
18 Oct 2002
Posts
32,623
I guess code reviews (if your company does them) should easily filter out this sort of code.

We don't hire people that code like that in the first place!


Just to be clear, the code blunder in my OP was from a customer. Their program sucked and kept failing, they would blame us and got us to restart the crashed server endlessly. In the end we said we would just recode their software for them if we are going to be responsible for uptime.

What is very scary is these people are responsible for most of the city/council software needs relating to transportation, and this is in a very big city
 
Last edited:
Caporegime
OP
Joined
18 Oct 2002
Posts
32,623
That is a complete synonym with what you have quoted, only you are on the side of the management in his post.

No, because we are allowed to refactor the code whenever we want and are constantly making tweaks as we see fit. What we don't do is have an official refactoring policy and set aside time. That is very different to what smyth was saying, their management don't let them and don't want the engineers spending time on refactoring, our managers don't care at all and let us do what we want but since we are always busy we don't have time to do serious refactoring. I could spend all weekend refactoring some of my code, or I could play with my daughter.
 
Caporegime
OP
Joined
18 Oct 2002
Posts
32,623
A common pattern I see is reversed conditional checks that needlessly indent code:

Code:
void someFunc()
{

  if (someVal == true) {
    // code
    // code
    if (someCondition) {
        //more indented code
        // more indented code
    }
    // code
    // code
  } else {
    // Sometimes this is omitted
    return;
  }
 
}

It is much cleaner to return early
Code:
void someFunc()
{

  if (someVal == false) 
       return;

  // code
  // code
  if (someCondition) {
        // indented code
        // indented code
  }
  // code
  // code

}
 
Caporegime
OP
Joined
18 Oct 2002
Posts
32,623
Yes, I hate this contortion of code to fit an artificial "THOU SHALT HAVE A SINGLE RETURN STATEMENT" rule. Makes the code so much more complex to follow.


Agreed, early exits are elegant and simple. You can get some horrifically convoluted code that is horribly complex series of nested if statements.

I think some people take certain recommendations far too literally rather than a suggestion.
 
Back
Top Bottom