• meow (unregistered)

    meow is the meow meow

    yep

  • octavio (unregistered)

    These comments are useful. The original programmers realized how hard it would be to figure out which closing brace was for which conditional.

  • Robo (unregistered)

    Bah, it makes total sense, they visually created a staircase, and the less likely the condition is, the steeper the slope - brillant!

  • iMalc (unregistered) 
    // Ffith

    // Forth // Thrid // Sekond // Frist!

  • (cs)

    Looks like they were using the Waterfall model.

  • null (unregistered)

    I guess a switch statement was too much trouble...

  • Captain Obvious (unregistered)

    Seems like it would make it easy to use find on page? I put in similar comments like // end $someconditional

  • (cs)

    This is very much common scenario for all legacy code. It is intentional on part of author and further succession of developers is also required mandatory to follow same pattern.

  • Nagesh (unregistered)

    This ain't much uncomon scenario for scarecrow code. It is intent on part of author and further massage of programer is also required mandatory to massage same patern.

  • J-L (unregistered) in reply to Captain Obvious
    Captain Obvious:
    Seems like it would make it easy to use find on page? I put in similar comments like // end $someconditional
    It would be easy to find until the day you decide to add some lines of code above the first condition. Then you'll be stuck updating all those line numbers.

    Or you could just not update the comments at all (I have a feeling that updating comments weren't a priority with these programmers), and just let those comments rot away, forever referring to incorrect line numbers.

    At least with your style of comment you can mentally tell which code block is ending without resorting to multiple keyboard presses and mouse clicks.

  • Nagesh (unregistered) in reply to J-L

    I ain't be massaging multiple keyboards.

  • (cs)

    I worked on a program like this once. Around 50 levels of nested IF; nested so deeply that, from time to time, the authors were "out-denting" the code, to keep it from getting indented too much.

    It took weeks to unravel that mess.

  • Recursive Reclusive (unregistered) in reply to J-L
    J-L:
    Captain Obvious:
    Seems like it would make it easy to use find on page? I put in similar comments like // end $someconditional
    It would be easy to find until the day you decide to add some lines of code above the first condition. Then you'll be stuck updating all those line numbers.
    Updating what line numbers? The conditional the endbracket is the end of, haven't changed.
  • Rawling (unregistered)

    I'm struggling to picture the top half of this code. else if statements don't lead to multiple close brackets.

  • swschrad (unregistered)

    it's a gust front in code, leading to a storm of uncontrollable random numbers.

  • (cs)

    TRWTF is the invalid octal number at the end. If you're going to write bad code, at least write syntactically correct comments!

  • (cs)

    I can think of about 3 different ways to write that depending on what the actual necessity of it was... switch, loops, ||...

    Should I consider myself lucky that I have never needed to solve a problem with 26 nested if statements?

  • Sizik (unregistered) in reply to Rawling
    Rawling:
    I'm struggling to picture the top half of this code. else if statements don't lead to multiple close brackets.

    It's probably nested if statements.

  • Christopher P Clark (unregistered)

    It's quite beautiful actually

  • AGray (unregistered)

    The best part of those closing braces is that they form a (nearly) perfect curve. It's (almost) pleasing to the eye.

    CAPTCHA: laoreet - the next Pokemon!

  • (cs) in reply to Nagesh
    Nagesh:
    I ain't be massaging multiple keyboards.
    You may return to your bridge now.
  • Charles (unregistered) in reply to J-L
    J-L:
    It would be easy to find until the day you decide to add some lines of code above the first condition. Then you'll be stuck updating all those line numbers.
    You mean your OS2/WARP IDE doesn't do that for you automatically?
  • anony-mouse (unregistered)

    Context of this sucks, does the comment above at if block 15 say what the code is for/does?

    Even then, shouldn't you be happy they added those? Yeah all the if blocks suck but at least you have a map.

  • Karel (unregistered) in reply to null

    They probably didn´t have a switch statement at that time.

  • J-L (unregistered) in reply to Recursive Reclusive
    Recursive Reclusive:
    J-L:
    Captain Obvious:
    Seems like it would make it easy to use find on page? I put in similar comments like // end $someconditional
    It would be easy to find until the day you decide to add some lines of code above the first condition. Then you'll be stuck updating all those line numbers.
    Updating what line numbers? The conditional the endbracket is the end of, haven't changed.
    Oh, I thought those numbers were line numbers. I can't quite tell for sure, but maybe they're level of nested if-blocks.

    At any rate, if someone decides to add another nested if-block somewhere in the middle, then they'll be stuck with updating all the numbers inside the new one.

    Or not. They could just put a new number (greater than the others) and allow the nested blocks to simply degrade into no particular order.

  • Kasper (unregistered) in reply to Rawling
    Rawling:
    I'm struggling to picture the top half of this code. else if statements don't lead to multiple close brackets.
    My thought exactly. A sequence like
    if (var == 1) {
} else if (var == 2) {
} else if (var == 3) {
    Would only be a minor WTF in a language supporting a switch statement. But let's assume this is a company that has a coding standard, and that coding standard requires the use of a compound statement after an if and after an else to avoid cases where you accidentally have a conditional not covering exactly what you expected it to. In other words constructions like
    if (x==1)
  y=2
else
  y=10;
    might have been banned in favor of constructions like:
    if (x==1) {
  y=2;
} else {
  y=10;
}
    This is a sensible requirement in many cases. However if it is applied to else if constructions it becomes ugly. If you apply this coding standard to the above sequence of else if statements you get
    if (var == 1) {
} else {
  if (var == 2) {
  } else {
    if (var == 3) {
    } // if (var == 3)
  } // if (var == 2) { } else {
} // if (var == 1) { } else {

    Commenting close brackets can be a good idea in some cases. If you do so, then indicate what sort of block you are closing. The comment is supposed to help not confuse even further. And such comments are mostly useful at the end of a long block.

    while (something_to_do) {
for (i=0; i<10 ; ++i) {
if (i == 5) {
// Code here
} else {
// More code here
} // if (i == 5) { } else
} // for (i=0; i<10; ++i)
} // while (something_to_do)

  • Jack (unregistered)

    I weep for all you poor starving children, who don't have vi and therefore can't automatically hop to the matching beginning or end brace with just two keystrokes.

  • Recursive Reclusive (unregistered) in reply to J-L
    J-L:
    Recursive Reclusive:
    J-L:
    Captain Obvious:
    Seems like it would make it easy to use find on page? I put in similar comments like // end $someconditional
    It would be easy to find until the day you decide to add some lines of code above the first condition. Then you'll be stuck updating all those line numbers.
    Updating what line numbers? The conditional the endbracket is the end of, haven't changed.
    Oh, I thought those numbers were line numbers. I can't quite tell for sure, but maybe they're level of nested if-blocks.
    I don't really know what the comments in the original code whas supposed to be, but the suggestion from Captain Obvious was along these lines:

    if (irish_girl) { if (paula) { if (!frist) { WTF WTF WTF WTF WTF WTF WTF } // endif !frist } // endif paula } // endif irish_girl

    If your nested blocks gets longer than a page (I know the shouldn't, but sometimes...) this is actually a good way to make the code more readable.

  • dogmatic (unregistered)

    You see? This is why java needs case switch statements for strings!

  • Nobody in particular (unregistered) in reply to Rawling
    Rawling:
    I'm struggling to picture the top half of this code. else if statements don't lead to multiple close brackets.

    They do if you're anal about bracing everything:

    if(foo){
    bar;
}else{
   if(baz){
      qux;
   }else{
      if(quux){
         etc;
      }
   }
}

    Technically, 

    else if
    is a "one-line" unbraced else.

  • Muwaah (unregistered)

    I want to see the code around it. What is it supposed to do? The number 26 makes me think it has something to do with alphabetizing, but the "09" at the bottom REALLY makes me wonder.

  • Federico (unregistered)

    Now that's a bad case of else-if-heimer.

  • (cs)

    This is all nonsense. The following is perfectly valid C:

    if (1) {
    if (2) {
        if (3) {
            if (4) {
                /* ... */
            } /* end if 4 */
        } /* end if 3 */
    } /* end if 2 */
} /* end if 1 */

    OK, so it's not perfectly useful C, but that's really a triviality.

  • (cs)

    I think the story's title, "Unconditionally Useless", is intended as a predictive description of the majority of the comments...

  • Guran (unregistered)

    OK, just to point out the obvious here:

    Commenting close brackets helps. Esp if the function is long. Yes the en-brackened code should not span a hundred lines, but we all know that happens, and if you at least made some decent comments, refactoring your mess becomes easier.

    But, as usual, these comments should be a direct translation of the code they are commenting. ( i = 1; //set i to one)

    if you do something like this

    if (i > 5) // explanation of why the first five are special { //long messy code here } else // we are no longer in the special case { //more messy code here }

    You might still have written crap code, but at least cleanable crap. Big difference.

  • TheSHEEEP (unregistered) in reply to Jack
    Jack:
    I weep for all you poor starving children, who don't have vi and therefore can't automatically hop to the matching beginning or end brace with just two keystrokes.

    The good thing is, though, that we don't need three years to master a 100% unintuitive writing system to write code faster than in normal IDEs.

    And besides, every useful IDE can do what you just described in few keystrokes.

  • Your Name (unregistered) in reply to J-L
    J-L:
    Recursive Reclusive:
    J-L:
    Captain Obvious:
    Seems like it would make it easy to use find on page? I put in similar comments like // end $someconditional
    It would be easy to find until the day you decide to add some lines of code above the first condition. Then you'll be stuck updating all those line numbers.
    Updating what line numbers? The conditional the endbracket is the end of, haven't changed.
    Oh, I thought those numbers were line numbers. I can't quite tell for sure, but maybe they're level of nested if-blocks.

    At any rate, if someone decides to add another nested if-block somewhere in the middle, then they'll be stuck with updating all the numbers inside the new one.

    Or not. They could just put a new number (greater than the others) and allow the nested blocks to simply degrade into no particular order.

    It's not an unsolvable problem, is it?

          } // else if 17
    } //else if 16.75
  } //else if 16.5
} //else if 16

    That's the beauty of this approach. If used correctly, you will never run out of numbers (in the correct order) for your blocks.

  • Honnza (unregistered) in reply to Your Name
    Your Name:
    J-L:
    Recursive Reclusive:
    J-L:
    Captain Obvious:
    Seems like it would make it easy to use find on page? I put in similar comments like // end $someconditional
    It would be easy to find until the day you decide to add some lines of code above the first condition. Then you'll be stuck updating all those line numbers.
    Updating what line numbers? The conditional the endbracket is the end of, haven't changed.
    Oh, I thought those numbers were line numbers. I can't quite tell for sure, but maybe they're level of nested if-blocks.

    At any rate, if someone decides to add another nested if-block somewhere in the middle, then they'll be stuck with updating all the numbers inside the new one.

    Or not. They could just put a new number (greater than the others) and allow the nested blocks to simply degrade into no particular order.

    It's not an unsolvable problem, is it?

          } // else if 17
    } //else if 16.75
  } //else if 16.5
} //else if 16

    That's the beauty of this approach. If used correctly, you will never run out of numbers (in the correct order) for your blocks.

    In that case, I suggest octal:

            } // else if 17
      } // else if 16.6
    } // else if 16.4
  } // else if 16.2
} // else if 16

    captcha: ACSI - any strict subset of ASCII, jumbled (such as EBC-DIC).

  • (cs)

    An indentation level of (at least) 19? Refactor it from orbit, it's the only way to be sure.

  • Mike (unregistered)

    It looks like a clumsy fudge to compensate for the bad tooling of the day.

  • Cbuttius (unregistered)

    It reminds you how many more braces you need to close.

    I came across bunches of nested-ifs when writing in C and you have to check the return value of every function call you make. Not sure it came to as many as 26 but certainly can get to 5 or 6.

    At each stage though the else would handle what failed and you would possibly need to clean-up the last thing that was properly allocated (the hidden "finally") after the if..else block.

    C++ is so much nicer for this.

  • RandomGuy (unregistered)

    Maybe it was the frist version of this earlier WTF.

    if(r == "IX") {
  r = "9";
} else {
  if(r=="X") {
    r = "10";
  } else {
    if(r=="XI") {
      // etc.
    } //if 11
  } // else if 10
} else if 09
  • Annon Too (unregistered)

    Right. Who's for just ripping it out and seeing what breaks? Anyone? Just me then?

    I'd say a refactoring is in order here.

  • Najeff (unregistered) in reply to TheSHEEEP
    TheSHEEEP:
    Jack:
    I weep for all you poor starving children, who don't have vi and therefore can't automatically hop to the matching beginning or end brace with just two keystrokes.

    The good thing is, though, that we don't need three years to master a 100% unintuitive writing system

    Don't be ridiculous! I've been using vi for 28 years and I still haven't mastered it.

  • (cs) in reply to Jack
    Jack:
    I weep for all you poor starving children, who don't have vi and therefore can't automatically hop to the matching beginning or end brace with just two keystrokes.
    Cry for me. I am an emacs user, where it takes one keystroke, not two, and where you can also jump to the enclosing brace with a single keystroke, not to mention differentiate an expression with 4.

    Have pity!

  • F (unregistered) in reply to TGV
    TGV:
    Jack:
    I weep for all you poor starving children, who don't have vi and therefore can't automatically hop to the matching beginning or end brace with just two keystrokes.
    Cry for me. I am an emacs user, where it takes one keystroke, not two, and where you can also jump to the enclosing brace with a single keystroke, not to mention differentiate an expression with 4.

    Have pity!

    I'm waiting for the editor that takes no keystrokes to do anything. Whoever is supposed to be producing it is certainly taking his time, and I wish he'd get a move on - I have stuff to get done.

  • (cs) in reply to dogmatic
    dogmatic:
    You see? This is why java needs case switch statements for strings!
    The current java does have Strings in switch-statements.

    Degrading one step further down to PHP in every new release...

  • (cs) in reply to no laughing matter
    no laughing matter:
    dogmatic:
    You see? This is why java needs case switch statements for strings!
    The current java does have Strings in switch-statements.

    Degrading one step further down to PHP in every new release...

    UPDATE: The example in chapter "Using Strings in switch Statements" is an epic fail of indeed nearly PHP-like dimensions.

    String.toLowerCase() uses the rules of the default locale. So set default locale to "tr TR" and test with:

    month="APRIL";
  • RandomGuy (unregistered) in reply to F
    F:
    TGV:
    Jack:
    I weep for all you poor starving children, who don't have vi and therefore can't automatically hop to the matching beginning or end brace with just two keystrokes.
    Cry for me. I am an emacs user, where it takes one keystroke, not two, and where you can also jump to the enclosing brace with a single keystroke, not to mention differentiate an expression with 4.

    Have pity!

    I'm waiting for the editor that takes no keystrokes to do anything. Whoever is supposed to be producing it is certainly taking his time, and I wish he'd get a move on - I have stuff to get done.

    This cries for the obligatory XKCD.

  • (cs) in reply to Captain Obvious
    Captain Obvious:
    Seems like it would make it easy to use find on page? I put in similar comments like // end $someconditional
    Protip: if you're doing it this way, you're doing something wrong...

Leave a comment on “Unconditionally Useless”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article