Comment On Unconditionally Useless

meow is the meow meow

yep

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

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

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

Looks like they were using the Waterfall model.

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

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

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.

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.

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.

I ain't be massaging multiple keyboards.

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.

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.

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

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

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

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?

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.

It's quite beautiful actually

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!

Nagesh:

I ain't be massaging multiple keyboards.

You may return to your bridge now.

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?

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.

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

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.

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)

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.

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.

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

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.

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.

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

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.

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

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.

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.

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.

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).

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

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

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.

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

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.

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.

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!

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.

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...

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";

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.

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...