• (cs)

    The only "real" reason why I have seen, and been told why not using braces on single-line if blocks is the maintenance issue.. I sometimes dont add braces to my if blocks because I find it more readable, why use 3 lines when you only need one? (e.g guard conditions at a start of a code block, you want to keep them small)

    Now, for those that start to get worried about their delicate fingers when needing to add braces, I have come up with an incredible solution (since I worry about mine too, and have needed to add braces) its called SURROUND WITH snippets..

    "Oh, I need add another line here, surround with, braces, type type type". Done.

    Although to be quite honest, I am now regretting even writing this comment because I really do not give a crap.

  • (cs) in reply to wds
    wds:
    The points of that link seems to be that 1) if you don't use bracers you might put a ";" behind the if. Which is a moot point because in java, if you put a bracer behind that if(false); and close it properly underneath it the code still compiles without warnings, and you still have a bug, bracers or no bracers. (at least with java 1.5, it's a rule in C and C-like languages that you can always start a locally scoped block anywhere in the code, without needing control statements around it)

    And 2) if you don't use bracers you might add a line of code beneath it that's not within the if-block. Now I see myself as an intermediate programmer at best, but on all the projects I've worked on except the very first (in college) I can't say I've ever made that mistake, and for those very early ones I'm sure there's plenty of other bugs that were harder to find for me as a beginning programmer.

    So it's "not recommended" for programmers just starting out, but for the rest of us in the real world it can eliminate some of those extraneous bracers on simple checks, making your code more and not less readable. It's really a matter of preference. There's no maintenance issue here.

    BTW the extra half-second it takes you to add bracers when you add a line (assuming your IDE is not completely retarded) is exactly the half second you saved writing the line in the first time. End sum = 0.

    Just out of curiosity, have you ever met someone else who refers to those symbols as "bracers" rather than "braces"? I've never heard such talk before.

  • (cs) in reply to Someone You Know

    I guess it avoids confusion with a dental brace?

    "Did you put your braces in?" "Are you saying I have bad teeth?"

    Ohhhhhh the trouble our terminology causes!

  • Albear (unregistered)

    I think my very faviate comment of all time was what i found in some work my a member of my team as i was updating it.

    //I have done it this way because i hate you!!

  • Code Guy (unregistered) in reply to Kluge Doctor

    Anyone that uses a conditional statement or loop without brackets is a jerk, for example:

    if (ima == "idiot")
  for (int i = 4; i < 33; i++)
    if (youra == "dumass")
      for (int ii = 34; ii < 234; ii++)
        Debug.Write("I can't write code!")

    .

    That's HORRIBLE code.

  • Code Guy (unregistered)

    Oh, and my favorite code comment:

    // Capture keys (they're fast f**kers)

  • wds (unregistered) in reply to Someone You Know
    Someone You Know:
    Just out of curiosity, have you ever met someone else who refers to those symbols as "bracers" rather than "braces"? I've never heard such talk before.
    Heh no that is just me posting with lack of coffee. At least I'm consistent in my misspellings. (I call them braces like everyone else, but I usually prefer brackets)

    BTW to the later poster, there's a difference between braceless-if with one statement beneath it and braceless-if with entire blocks beneath it. I was talking about the former.

  • (cs)

    This forum software offers the possibility to post completely useless comments. Although it is generally not recommended, I'll just post one here, so you can recognize them in the future in case you come across one in some other forum.

  • (cs) in reply to wds

    Yeah I know, one will compile, one wont :)

    My coffee is broken, Ive been half asleep all day! :(

  • Jay (unregistered)

    I've seen plenty of comments in programs that explain the programming language rather than the program. Like, I used to work on a system that was filled with examples like:

    n17=n4+n12; // Add n4 to n12

    i.e. all the variable names were "n" followed by a number, and the comments were like the above.

    So, uh, yeah. If I was really struggling with that obscure feature of C that "+" means "add", this might be helpful. But what I really need to know is: What in the world do those variables contain?

  • iToad (unregistered)

    In some of the code that I come across, I'd be happy to find -any- comments, useless or not.

  • myddrin (unregistered) in reply to SenTree

    Sadly, it wasn't a manager... it was "the lead programmer". (At the time, I was the junior most developer on the project. Within 6 months, I was "the lead"...)

  • Jay (unregistered)

    Once a co-worker of mine asked for help with a program that was giving incorrect results and she just couldn't figure it out. The code went something like:

    while (getNextMessage());
{
  ... bunch of code to process message ...
}

    I looked at it and didn't see the problem either. We ran it with a debugger and for some mysterious reason the loop just quit after one iteration no matter what the data. I spent a lot of time studying the getNextMessage() function to figure out why it would return false when there were clearly more messages in the queue.

    Well, from the context of this thread and the fact that I left out all the complicated code, you probably see the dumb error -- the semicolon after the while statement. But we worked on it for hours before that finally registered on me.

    The moral being that even smart people like myself and my friend can miss dumb mistakes. And that a substantial percentage of program bugs are probably that sort of dumb mistake rather than some fundamental flaw in the logic.

  • Steve (unregistered) in reply to myddrin
    myddrin:
    That wasn't the only oddity, all the variable names were two letters, which were apparently selected at random. (Or perhaps the logic of their selection was beyond me....)

    When I asked my nominal superior on the project about that, I was told that "Long variable names make the code run slower or something. I don't know, that's what I was told."

    There's a kernel of truth to that -- or at least there was. Waaaaaaaaay back when eight bit dinosaurs roamed the land, some BASIC interpreters would indeed run slower with longer variable names, since it would take longer to parse and look up the variable.

    Comments were also often stripped out, since they (a) made the code run slower, since the interpreter would have to skip forward over the bytes and (b) since memory was at a premium, they took up too much space.

    Smarter BASIC interpreters, of course, would do some optimization and caching but old habits sometimes die hard.

    For instance, since I learned programming on an early variant of FORTRAN called GOTRAN, a so-called "load and go" compiler with extremely limited capabilities, I sometimes find myself overparenthesizing expressions, since, I believe, the operator precedence was strictly left to right and coding something like

    A = B * B + C * C
    would produce an unexpected result.

  • Villa (unregistered)

    I love how he wasted at least twice as many lines as the ones he "saved" by not using braces.

  • ais523 (unregistered) in reply to Jay

    I've been known to comment every line of a program like that when learning an assembly langugage. However, that's just as a learning tool, and not intended for production code. (I don't write production code in assembly language anyway, so the chance of such comments getting in to such code is minimal.)

  • zoips (unregistered)

    I wrote a comment like this once...for Javascript...mainly because most people seem to have never considered immediate execution of functions by wrapping their definition in parenthesis which makes the function the result of an expression...

  • bramster (unregistered)

    I program in C

    It is terse.

    omments are appreciated.

  • Anon (unregistered) in reply to Jay
    Jay:
    I've seen plenty of comments in programs that explain the programming language rather than the program. Like, I used to work on a system that was filled with examples like: 
    n17=n4+n12; // Add n4 to n12

    i.e. all the variable names were "n" followed by a number, and the comments were like the above.

    So, uh, yeah. If I was really struggling with that obscure feature of C that "+" means "add", this might be helpful. But what I really need to know is: What in the world do those variables contain?

    Hmm, I thought 4 + 12 = 16, not 17.

    Oh wait...

  • Loren Pechtel (unregistered) in reply to Eric Shinn
    Eric Shinn:
    I shy away from that coding style; you can't set a breakpoint inside the if.

    Even if it's just

    if (param == null) return;

    I like it on two lines.

    I definitely agree. It's also clearer.

  • JPM (unregistered) in reply to shadowman
    shadowman:
    wds:
    And 2) if you don't use bracers you might add a line of code beneath it that's not within the if-block. Now I see myself as an intermediate programmer at best, but on all the projects I've worked on except the very first (in college) I can't say I've ever made that mistake, and for those very early ones I'm sure there's plenty of other bugs that were harder to find for me as a beginning programmer.

    So it's "not recommended" for programmers just starting out, but for the rest of us in the real world it can eliminate some of those extraneous bracers on simple checks, making your code more and not less readable. It's really a matter of preference. There's no maintenance issue here.

    LOL. I just did that yesterday while working with someone else's code, and I've been doing this for more than a couple years now. Of course, I caught it after the program didn't work right.

    Still, that wouldn't stop me from writing single-line if statements without brackets; it's a valid style.

    Lol! I bet your project manager doesn't agree.

    Here's an idea for extending C# though. We've already got:

    // to comment a line or /// for documenting a class interface

    how about a new one

    //// for really patronizing comments? That way they can be automatically extracted from source files and used for... err... something.

  • commenter (unregistered)

    I'm posting this comment to show how one might ask a dumb question.

    So, did anyone mention that File.Delete doesn't throw an exception if the file doesn't exist?

  • (cs) in reply to Jay
    Jay:
    The moral being that even smart people like myself and my friend can miss dumb mistakes.
    I spent 1996 through 2000 using VB versions 4 through 6 (company policy; I was a C++ guy when I got there). In VB, parentheses on methods are optional, so of course neither I nor anyone else used them: why type any extra keystrokes?

    So when I started working with javascript, I brought my VB laziness with me. It took me two hours of pulling my hair out to finally figure out why this wouldn't work:

    document.forms[0].submit;
  • (cs) in reply to topcat_arg
    topcat_arg:
    ' This comment is in case you are hungry ' McDonald's phone 555-5555
    ' 20-MAY-2008 operagost Corrected "mac donalds" to "McDonald's," and removed reference to nonexistent delivery service.
  • L33tminion (unregistered)

    Bet you that snippet (comment and all) was copied from a CS textbook or the like...

  • Jason Stokes (unregistered)

    So it's someone from a Java background who hasn't seen this C-style idiom before. Big deal. If the developer sees something which seems odd or in need of explanation to her, she should comment it. Its better to have well-commented code with the occasional trivial comment than undercommented code with none.

  • Andrew (unregistered)

    The only WTF was the this programmer didn't get his "Enter" pinky amputated.

    Any programmer too lazy to put braces around a single line "then" clause should be fired on the spot. It will save numerous bugs down the road.

  • Andrew (unregistered) in reply to Jay
    Jay:
    I've seen plenty of comments in programs that explain the programming language rather than the program. Like, I used to work on a system that was filled with examples like: 
    n17=n4+n12; // Add n4 to n12

    i.e. all the variable names were "n" followed by a number, and the comments were like the above.

    So, uh, yeah. If I was really struggling with that obscure feature of C that "+" means "add", this might be helpful. But what I really need to know is: What in the world do those variables contain?

    n4 is hydrogen peroxide. n12 is Tang.

  • Eric (unregistered)

    Umm...is file even defined in this function?? Does this compile???

  • Anonymous Coward (unregistered) in reply to kevin

    The real WTF is the obvious race condition. By the time File.Delete is called, the file may already have been deleted by another process. So the call to File.Exists is not only redundant, but flat-out incorrect.

  • beatfreek (unregistered) in reply to tdittmar

    this beauty from our codebase.....

    ///

    ///This interface defines method signatures. /// interface IWhatever { ... }

  • GregP (unregistered)

    I have a co-worker that likes to copy example code and leave in the comments. We work in a custom language, so it isn't quite as bad as the example.

    And he usually only does it for complicated things that most of the rest of our group don't touch. So a case could be made he left in the explanation of the rest of them.

    It just leaves a bad taste in my mouth because it seems like he's just copying and pasting withouth know what he's doing, even through I know he does.

  • (cs) in reply to Andrew
    Andrew:
    The only WTF was the this programmer didn't get his "Enter" pinky amputated.

    Any programmer too lazy to put braces around a single line "then" clause should be fired on the spot. It will save numerous bugs down the road.

    It will also result in an IT department full of anally-retentive cretins.

    At the end of the day, I suppose it depends upon what sort of work environment you're aiming for, really.

  • (cs) in reply to real_aardvark
    real_aardvark:
    At the end of the day, I suppose it depends upon what sort of work environment you're aiming for, really.
    At the end of the day I'm aiming for home and a kiss, a hug, and a cool one, and I don't give a damn what sort of work environment I have. It's at the beginning of the day that that sort of thing starts to matter.
  • Tmi (unregistered) in reply to ClaudeSuck.de

    The WTF is that between the test for existence, and the attempt to delete, something else may have happened to the file.

    I don't know what C# does if you attempt to delete a file that doesn't exist - in some languages it returns an error code, others a boolean (success/failure), others throw an exception.

    The correct thing to do is simply attempt to delete, and handle failure.

  • ben (unregistered)

    In assembly you can write code the controls your processor. I find this interesting.

  • fluffy777 (unregistered) in reply to tdittmar

    // I // get // paid // by // the // line.

  • Craig Beere (unregistered) in reply to tdittmar
    tdittmar:
    // In C# you can use single line comments using "//" // If you do that for more than one line, you've // got multi-line comments without using /* ... */ // I just put this here in case you see it in other // modules...

    // Personally I don't like this style of comment because when // you edit your comments then you have // to go through and rearrange all the double-slashes or // asterisks or whatever you've used. This is made even worse if you // (like me) use a non-proportional font in your // editor.

    In response to a couple of other comments here:

    I don't think brackets of any kind are ever extraneous. At the cost of a few more presses of keys you get code that is less ambiguous and clearer to read (for both humans and compilers).

    I do think anal-retentiveness is required for programming. Programming languages are picky beyond belief. Miss one semicolon and you're history. Miss a digit in a format statement and your reactor melts down.

    Cheers Craig

  • Steve (unregistered) in reply to ClaudeSuck.de
    ClaudeSuck.de:
    TRWTF are the ads below the post. Voilà!

    TRWTF is surfing the Internet without blocking adverts, popups and Flash.

  • FatherStorm (unregistered)

    SOunds like projects that I've been on that counted progress in lines of code. Useless comments count as work!

  • Noodle (unregistered) in reply to tdittmar

    LOL, recognize that only crappy coders take shortcuts and do not use proper verbose shortcuts, comment on it, then do it.

    Dumbass...

  • (cs) in reply to Jason Stokes
    Jason Stokes:
    So it's someone from a Java background who hasn't seen this C-style idiom before. Big deal. If the developer sees something which seems odd or in need of explanation to her, she should comment it. Its better to have well-commented code with the occasional trivial comment than undercommented code with none.

    One day we can only hope that Java will support such C-style intricacies as writing single line if statements without braces.

    Actually, lets be realistic the chances of that ever happening are almost as slim as people one day being able to write short obfuscated programs in Perl or low level programs in Assembly.

  • The Real WTF (unregistered) in reply to ClaudeSuck.de
    ClaudeSuck.de:
    And so what? Where is the WTF? This code deletes a file if it exists. The comment, though, makes the former programmer a little professorish, but that's all.

    And BTW: Frist

    /* If errors are found in this code, fire Claude, not me. */

  • Brendan (unregistered) in reply to A Nonny Mouse
    A Nonny Mouse:
    private void Form1_FormClosing(object sender, FormClosingEventArgs e)
    if (System.IO.File.Exists(file)) System.IO.File.Delete(file);

    is so much neater..

    import System.IO
...
if (File.Exists(file))
   File.Delete(file);
...

    this is much more neater, but you didn't mention that.

    PS: don't forget to put in your name, you'll be waiting a while. And lets speed this server up a bit hey.

  • (cs) in reply to Jay
    Jay:
    Once a co-worker of mine asked for help with a program that was giving incorrect results and she just couldn't figure it out. The code went something like: 
    while (getNextMessage());
{
  ... bunch of code to process message ...
}

    I looked at it and didn't see the problem either. We ran it with a debugger and for some mysterious reason the loop just quit after one iteration no matter what the data. I spent a lot of time studying the getNextMessage() function to figure out why it would return false when there were clearly more messages in the queue.

    Well, from the context of this thread and the fact that I left out all the complicated code, you probably see the dumb error -- the semicolon after the while statement. But we worked on it for hours before that finally registered on me.

    The moral being that even smart people like myself and my friend can miss dumb mistakes. And that a substantial percentage of program bugs are probably that sort of dumb mistake rather than some fundamental flaw in the logic.

    The moral of the story is to use a modern day compiler that will point out mistakes like this.

  • Brendan (unregistered) in reply to Jay
    Jay:
    Once a co-worker of mine asked for help with a program that was giving incorrect results and she just couldn't figure it out. The code went something like: 
    while (getNextMessage());
{
  ... bunch of code to process message ...
}

    I looked at it and didn't see the problem either. We ran it with a debugger and for some mysterious reason the loop just quit after one iteration no matter what the data. I spent a lot of time studying the getNextMessage() function to figure out why it would return false when there were clearly more messages in the queue.

    Well, from the context of this thread and the fact that I left out all the complicated code, you probably see the dumb error -- the semicolon after the while statement. But we worked on it for hours before that finally registered on me.

    The moral being that even smart people like myself and my friend can miss dumb mistakes. And that a substantial percentage of program bugs are probably that sort of dumb mistake rather than some fundamental flaw in the logic.

    The real moral is to put th brace at the end of the while loop (if you want one). For example:

    while (getNextMessage()) {
  ... bunch of code to process message ...
}
  • nog_lorp (unregistered) in reply to tdittmar

    { ; in C#, semicolons do not designate commas ; and if you try to use them instead of /* */ ; or // you will have errors ; I'm just putting this so you won't make that mistake. }

  • blyth (unregistered)

    this is useful ... NOOOOT!

  • ClaudeSuck.de (unregistered) in reply to Hans
    Hans:
    ClaudeSuck.de:
    And so what? Where is the WTF? This code deletes a file if it exists. The comment, though, makes the former programmer a little professorish, but that's all.

    Apparently the real WTF here is that some of us don't care enough about good comments that they don't even see the WTF.

    Danke Hans. If you need comments of this kind then I must doubt your programming capabilities. One of the rules for comments is that thou shalt not comment stuff which is obvious. It distracts and disturbs to have rubbish comments. Say why the piece of code is executed but don't give programming lessons in the code.

  • ClaudeSuck.de (unregistered) in reply to SenTree
    SenTree:
    myddrin:
    When I asked my nominal superior on the project about that, I was told that "Long variable names make the code run slower or something. I don't know, that's what I was told."
    No, no, no! They make it bigger. Trust a manager to get it wrong.

    Remember the old DOS days with GW-BASIC and other flavors of it. It was quite common that variables had only two characters because that was the maximum recognicable length for the interpreter. More characters were allowed but they were not significant for the distinction of variables. Hence AB1 was the same variable as AB2 since only AB was used by the interpreter to define the name of the variable. Thus, I suppose the superior probably still had the number 2 in mind but didn't remember why only 2 had to be used. You know, after years of programming and then several years after this can actually happen.

Leave a comment on “That's... Helpful”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article