• (cs) in reply to Manni
    <!--StartFragment -->
    Manni:
    Quit mocking the underprivileged pizza-less readers, you insensitive bastard.


    You do not have Friday pizza?  (Pepperoni, too, which matches the icon.)

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Anonymous
    Anonymous:

    Having curly braces on a seperate line allows you to easily scan to verify bracers match correctly.  Yes, that's trivial, but so is your argument.

    That said, it's a design style.  It's like arguing about whether to use pre- or post- unary operators.  Stick with whatever your companies coventions are.

    That isn't a style. That's something that has real-world performance implications that can be quite significant. In C++ the postfix ++ operator requires that a temporary be made, then destroyed, and the prefix one does not. So, I do strongly recommend that everybody always use prefix when it's convenient. This is even in cases where it doesn't really matter, because the habit is a good one.

    But, yes, the curly brace thing is a style. And I generally leave code alone that uses a style I don't like (except when it comes to the space/tab issue), and I tend to try to adopt the style in common use in the codebase I'm working on.

  • Emmanuel D. (unregistered) in reply to Djinn
    Djinn:


    Careful with that axe, Eugene.

    int a = 0;

    a = a++ + 1;
    System.out.println(a);

    a = ++a + 1;

    System.out.println(a);

    Run that in Java. Now, switch to C/C++ (changing variable printing accordingly), and run it against many different compilers/platforms.



    I have to say "no". There is two sequence ponits here - the result is that your C++ expression is not covered by the standard. This is the bullet in the famous expression of Stroustrup.

    Now, one must be very careful with post and pre increment. Tecnhically speaking, using post increment is less usefull than using pre increments, and shouls only be used when necessary. Pre-increment should be the rule, because it avoids an unnecessary temporary copy of the incremented lvalue. Of course, if this lvalue is of one of the POD types, then the optimizer will probably produce the right code. But if the lvalue is (for example) an iterator then a post increment may involve a lot of unnecessay operations.

    Now, I really like Jed's code, and I'm probably going to have some fun tomorrow with our source code repository (maybe we can hire Jed's?)

  • (cs) in reply to Djinn
    Djinn:
    Careful with that axe, Eugene.

    int a = 0;

    a = a++ + 1;
    System.out.println(a);

    a = ++a + 1;

    System.out.println(a);

    Run that in Java. Now, switch to C/C++ (changing variable printing accordingly), and run it against many different compilers/platforms.



    In C, modifying a variable twice between evaluation points has undefined results.  You could get anything.

    Sincerely,

    Gene Wirchenko

  • frosty (unregistered) in reply to Jenny Simonds
    Jenny Simonds:
    Alex Papadimoulis:

    In addition to all 250+ opening curly braces being moved to the same line as the method/if/while statement, the argument validation was just no longer working.

    The "before" version ...

    Neither version has any curly braces that I can see. This is bad form. Every if & while should use curly braces to enclose the block, even if there's only zero or one statement inside it. The extra braces are a small price to pay for consistency & clarity, & the decreased risk when someone comes along & adds another statement to the block.

    <font size="1">(Just-cuz-the-language-lets-you-do-it-doesn't-mean-it's-a-good-idea dept.)</font>



    I would like to make an addition to this:

    - If you are trying to fit more lines of code on your screen, have you thought of getting a larger screen?  What about using the scroll bar?
    - If a blank line is used to seperate code blocks, shouldn't if statments be even more important to make very clear and easy to see?
  • (cs) in reply to frosty

    <P>Has anyone ever published a survey on how many people code with the various curly brace styles?</P>
    <P>I use an old-school format which used to be popular in Windows-world, like this:</P>
    <BLOCKQUOTE><PRE>
    {
    <FONT color=#008000>// snip</FONT>
     
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <FONT color=#0000ff>if</FONT> (szFilename[0])
        {
        eRet = ValidateFilename (szFilename);
        if (eRet==retOK)
            {<FONT color=#008000>// Process the file...</FONT>
            eRet = DoSomethingWithFile (szFilename);
            }
       
        return eRet;
        }
    }</PRE></BLOCKQUOTE>

    instead of the (inferior IMO :) BSD style:

    <BLOCKQUOTE><PRE>
    {
        <FONT color=#008000>// snip</FONT>
     
        m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
        <FONT color=#0000ff>if</FONT> (szFilename[0])
        {
            eRet = ValidateFilename (szFilename);
            if (eRet==retOK)
            {<FONT color=#008000>// Process the file...</FONT>
                eRet = DoSomethingWithFile (szFilename);
            }
           
        return eRet;
        }
    }</PRE></BLOCKQUOTE>

    or the (even worse) K&R style:

    <BLOCKQUOTE><PRE>
    {
        <FONT color=#008000>// snip</FONT>
     
        m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
        <FONT color=#0000ff>if</FONT> (szFilename[0])) {
            eRet = ValidateFilename (szFilename);
            if (eRet==retOK) {
                <FONT color=#008000>// Process the file...</FONT>
                eRet = DoSomethingWithFile (szFilename);
            }
           
        return eRet;
        }
    }</PRE></BLOCKQUOTE>

    My style is in a clear minority nowadays, judging by the code I've seen over the years,
    but I wonder just how minor it is.

  • (cs) in reply to Jenny Simonds

    Has anyone ever published a survey on how many people code with the various curly brace styles?

    I use an old-school format which used to be popular in Windows-world, like this:

    {
    <FONT color=#008000>// snip</FONT>
    

    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename)); <FONT color=#0000ff>if</FONT> (szFilename[0]) { eRet = ValidateFilename (szFilename); if (eRet==retOK) {<FONT color=#008000>// Process the file...</FONT> eRet = DoSomethingWithFile (szFilename); }

    return eRet;
    }
    

    }

    instead of the (inferior IMO :) BSD style:

    {
        <FONT color=#008000>// snip</FONT>
    
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <FONT color=#0000ff>if</FONT> (szFilename[0])
    {
        eRet = ValidateFilename (szFilename);
        if (eRet==retOK)
        {<FONT color=#008000>// Process the file...</FONT>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    or the (even worse) K&R style:

    {
        <FONT color=#008000>// snip</FONT>
    
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <FONT color=#0000ff>if</FONT> (szFilename[0])) {
        eRet = ValidateFilename (szFilename);
        if (eRet==retOK) {
            <FONT color=#008000>// Process the file...</FONT>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    My style is in a clear minority nowadays, judging by the code I've seen over the years, but I wonder just how minor it is.

  • (cs) in reply to Jenny Simonds
    Jenny Simonds:
    {
    <FONT color=#008000>// snip</FONT>
    

    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename)); <FONT color=#0000ff>if</FONT> (szFilename[0]) { eRet = ValidateFilename (szFilename); if (eRet==retOK) {<FONT color=#008000>// Process the file...</FONT> eRet = DoSomethingWithFile (szFilename); }

    return eRet;
    }
    

    }

    ACK! The "return eRet" goes down a line of course.

  • K (unregistered) in reply to jose cuervo

    throw new oldWord ("Obfuscate")

    /* That's the term you're all looking for here */

    From the tech.writer in the audience.

  • JV (unregistered) in reply to Jenny Simonds

    I'm guessing our friend Jed had a bad case of fat fingers, popular with the ladies but not with code... Not that I'm defending him. Anyone who doesn't check his/her code at least half a dozen times deserves to be mocked publicly. If we could only find a way to do that...

  • slimey_limey (unregistered)

    Alex Papadimoulis:

    if ((threshold) <= 0 || (threshold) >= 1) invalidArgs ++;

    Am I the only person who saw the unbalanced parentheses on this line?

  • David Wolever (unregistered) in reply to Djinn

    Attritioned is not in a dictionary because the word is attrition.
    http://dictionary.reference.com/search?q=attrition

    4. A gradual, natural reduction in membership or personnel, as through retirement, resignation, or death.

    Sounds a 'bout right

  • Anonymous (unregistered) in reply to slimey_limey
    Anonymous:

    Alex Papadimoulis:

    if ((threshold) <= 0 || (threshold) >= 1) invalidArgs ++;

    Am I the only person who saw the unbalanced parentheses on this line?



    No, and now that you bring it up, I still don't see it.
  • (cs) in reply to Jenny Simonds
    Jenny Simonds:
    Has anyone ever published a survey on how many people code with the various curly brace styles?


    Yikes!  Flames!

    I use an old-school format which used to be popular in Windows-world, like this:

    {
    <font color="#008000">// snip</font>

    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename)); <font color="#0000ff">if</font> (szFilename[0])
    {
    eRet = ValidateFilename (szFilename);
    if (eRet==retOK)
    {<font color="#008000">// Process the file...</font> eRet = DoSomethingWithFile (szFilename); }

    return eRet;
    }
    

    }



    My style is in a clear minority nowadays, judging by the code I've seen over the years, but I wonder just how minor it is.


    I use that style myself.  I developed it myself (and expect many others have, too).  Since a block-structured language is one in which
         <font size="2"><block> ::= <block_start_delimiter> <statement> ... <block_end_delimiter></font>
    it makes sense to me to have statements and block delimiters at the same level of indentation.  This style also transfers well across different programming languages.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Russ
    Anonymous:

    Everyone loves made up words.  My favorite one that I made up is "ambigufy" - logic being:

    Clear -> Clarity and Clarify

    Ambiguous ->  Ambiguity and ____?  - Hence, ambigufy!



    Your GRE scores must be near the bottom. By your logic, it'd be "ambiguify", not "ambigufy". I'd say it's a typo on your part, but you spelled it that way twice.
  • (cs) in reply to Jenny Simonds
    Jenny Simonds:

    Has anyone ever published a survey on how many people code with the various curly brace styles?

    I use an old-school format which used to be popular in Windows-world, like this:

    {
    <font color="#008000">// snip</font>

    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename)); <font color="#0000ff">if</font> (szFilename[0])
    {
    eRet = ValidateFilename (szFilename);
    if (eRet==retOK)
    {<font color="#008000">// Process the file...</font> eRet = DoSomethingWithFile (szFilename); }

    return eRet;
    }
    

    }

    instead of the (inferior IMO :) BSD style:

    {
    <font color="#008000">// snip</font>
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <font color="#0000ff">if</font> (szFilename[0])<br>    {<br>        eRet = ValidateFilename (szFilename);<br>        if (eRet==retOK)<br>        {<font color="#008000">// Process the file...</font>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    or the (even worse) K&R style:

    {
    <font color="#008000">// snip</font>
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <font color="#0000ff">if</font> (szFilename[0])) {<br>        eRet = ValidateFilename (szFilename);<br>        if (eRet==retOK) {<br>            <font color="#008000">// Process the file...</font>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    My style is in a clear minority nowadays, judging by the code I've seen over the years, but I wonder just how minor it is.



    The first style amounts to a double indentation. This to me is confusing: where's the first level?
    The second style is perfect and sublime.
    The third style is deserving of torture and public ridicule.

  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:

    I use that style myself.  I developed it myself [...]

    Sincerely,

    Gene Wirchenko


    Maybe you're the only person who reads your code, but many people read (and will read) my code both during development and into maintenance. Developing a new standard just doesn't make much sense. Obey the Golden Rule: code as you would have others do (if you're maintaining their code).

    Sincerely,

    Get a new Signature
  • Anonymous (unregistered) in reply to slimey_limey
    Anonymous:

    Alex Papadimoulis:

    if ((threshold) <= 0 || (threshold) >= 1) invalidArgs ++;

    Am I the only person who saw the unbalanced parentheses on this line?



    Yes.  I see there opened, and three closed.  They're even in the right places, too.

  • (cs) in reply to rogthefrog
    rogthefrog:

    The first style amounts to a double indentation. This to me is confusing: where's the first level?
    The second style is perfect and sublime.
    The third style is deserving of torture and public ridicule.


    Absolutely.

    (Except the "return" statement in the second style needs to be indented one more level.  And perhaps torture is a little strong.)
  • Coward (unregistered) in reply to Anonymous

    Anonymous:
    That said, it's a design style.  It's like arguing about whether to use pre- or post- unary operators.  Stick with whatever your companies coventions are.

    They aren't the same thing at all, at least in C++.

  • (cs)

    I think you REALLY meant attritted.  If I hadn't been watching Donald Rumsfeld's Pentagon briefings, I wouldn't know of this verb-tense word.

    from http://dictionary.reference.com/search?q=attritted

    1. To lose (personnel, for example) by attrition.
    2. To destroy or kill (troops, for example) by use of firepower: “Pro-active counterattacks are a useful way to attrit the enemy” (John H. Cushman, Jr.).
  • (cs) in reply to John Smallberries
    John Smallberries:
    Gene Wirchenko:

    I use that style myself.  I developed it myself [...]

    Sincerely,

    Gene Wirchenko


    Maybe you're the only person who reads your code, but many people read (and will read) my code both during development and into maintenance. Developing a new standard just doesn't make much sense. Obey the Golden Rule: code as you would have others do (if you're maintaining their code).

    Sincerely,

    Get a new Signature


    I follow what is used if on multi-person programs, but on my own, I use my style.  I developed the base of it about twenty-five years ago, so it is not new.  Others have developed similar schemes.  If I have to use something, I prefer to use what I prefer.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to slimey_limey
    Anonymous:

    Alex Papadimoulis:

    if ((threshold) <= 0 || (threshold) >= 1) invalidArgs ++;

    Am I the only person who saw the unbalanced parentheses on this line?



    They're not actually unbalanced. They're just very weird; why would you put parentheses around a variable name on its own? Either of the following two lines is probably what was meant:


  • (cs)

    one of the few times I laughed first - instead of just going straight to pissed off.

    Jed is a pioneer.  Everyone should respect his authority because he's a Senior Developer.  You can't argue that now can you?

     

  • (cs) in reply to Maurits

    Maurits:
    rogthefrog:

    The first style amounts to a double indentation. This to me is confusing: where's the first level?
    The second style is perfect and sublime.
    The third style is deserving of torture and public ridicule.


    Absolutely.

    (Except the "return" statement in the second style needs to be indented one more level.  And perhaps torture is a little strong.)

    I was going to comment on that return statement but then I ran into the famed WTF that you can't edit your posts. It didn't seem to deserve a new message.

    Now - no torture is strong ENOUGH punishment for that horrid brace style. It's so bad I wrote a script to reformat a coworker's code I had to maintain so I could spend my time reading the code instead of hunting for that FRICKIN' opening brace.

  • (cs) in reply to Gene Wirchenko
    Gene Wirchenko:
    Djinn:
    Careful with that axe, Eugene.

    int a = 0;

    a = a++ + 1;
    System.out.println(a);

    a = ++a + 1;

    System.out.println(a);

    Run that in Java. Now, switch to C/C++ (changing variable printing accordingly), and run it against many different compilers/platforms.



    In C, modifying a variable twice between evaluation points has undefined results.  You could get anything.

    Sincerely,

    Gene Wirchenko


    I'm beginning to think you do that just to piss Dick Nixon off.

    Something I can always get behind.

  • (cs) in reply to Emmanuel D.

    Are you agreeing with my observation that it's wrong, or did you think I thought that was a good idea? I put that line in there about running it on many different platforms/compilers exactly for that reason. I chose the example also because it's intresting what happens in java (didn't test elsewhere) when you assign a variable the same variable's post-increment.

  • (cs) in reply to Jenny Simonds

    Hi everyone! I've been lurking, now I am posting. And then I will get flamed :)

    Jenny Simonds:

    or the (even worse) K&R style:

    {
        <FONT color=#008000>// snip</FONT>
    
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <FONT color=#0000ff>if</FONT> (szFilename[0])) {
        eRet = ValidateFilename (szFilename);
        if (eRet==retOK) {
            <FONT color=#008000>// Process the file...</FONT>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    I am picking up C#, coming from of VB6 and TSQL. So I am learning a lot from the discussions here!

    In TSQL I usually use the following to make is easier to find the start and end:

    if @TestVar=1 begin
       set @SomeVar=@SomeVar + 1
       ... etc ...
    end --if

    Note that '--' is the TSQL inline comment delimiter, so --if is a comment

    And I must say, that *is* one way VB and TSQL beats out C-style languages - the block markers are big enough that they don't vanish when you squint!

     

     

     

     

     

     

    <FONT face="Courier New"></FONT>
  • (cs) in reply to koedoot
    koedoot:
    But giving too detailed error messages does not give your program a professional look

    True, but irrelevant. Nothing proposed here was "too detailed". Users get pissed off when they get no feedback about in what way an argument was invalid. Support staff get even more pissed off when they can't give a useful explanation.

    Too detailed is a coredump. An actual specific explanation of what's wrong with the arguments is not "too detailed".

    I will take a program that can be used and worked with over a "professional look" that's completely unusable in reality any day of the week.

  • (cs) in reply to Noisy Crow
    Noisy Crow:

    Hi everyone! I've been lurking, now I am posting. And then I will get flamed :)

    I am picking up C#, coming from of VB6 and TSQL. So I am learning a lot from the discussions here!

    In TSQL I usually use the following to make is easier to find the start and end:

    if @TestVar=1 begin
       set @SomeVar=@SomeVar + 1
       ... etc ...
    end --if

    Note that '--' is the TSQL inline comment delimiter, so --if is a comment

    And I must say, that *is* one way VB and TSQL beats out C-style languages - the block markers are big enough that they don't vanish when you squint!


    Well, you knew it was coming.  Single char block grouping delimiters are far better than blocks marked with words.

    Allow me to demonstrate...

    Open up a C style language source file in vi.  Put the cursor over any opening delimiter, be it '(', '{', or '['.  Then press the % key.  Viola!  The editor has immediately found the match.  Press % again and go back to the starting delimiter.  Is the indent level wrong?  Press &gt;, then % and move the entire block in one level.  Need to delete the entire block?  Press d then %.  Need to copy the entire block to a cut and paste buffer?  Press y then %.

    It is much more difficult to do these kinds of operations in word delimited languages.  Now I'm sure that there are some good editors out there that can do these kinds of things for one language on one platform.  Of course when I change languages or platforms I'd need to learn an all new commands.  I'd much rather use the same editor everywhere.  And with vi/vim (www.vim.org) I can do so freely and easily.

  • Anonymous (unregistered) in reply to rogthefrog

    Putting the opening brace on its own line does nothing but reduce the amount of code you can see on your screen at once, forcing you to scroll more.

  • ColdPie (unregistered) in reply to rogthefrog
    rogthefrog:
    Jenny Simonds:

    Has anyone ever published a survey on how many people code with the various curly brace styles?

    ...

    or the (even worse) K&R style:
    {
    <font color="#008000">// snip</font>
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <font color="#0000ff">if</font> (szFilename[0])) {<br>        eRet = ValidateFilename (szFilename);<br>        if (eRet==retOK) {<br>            <font color="#008000">// Process the file...</font>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    	return eRet;
    }
    

    }


    ...

    The third style is deserving of torture and public ridicule.



    (Note: I fixed the return line to demonstrate my point...)
    I use the third style myself.  It's just what I learned, and I find it uses the least excess whitespace and keystrokes.  From what I've seen, it's also the most popular.  In reply to someone who said that  it's difficult to find the matching open brace:  That's what indentation is for.  If you need to find the matching open brace for a given close brace, simply look up until you find the last line at that indentation level.

    Begin the torture and ridicule :)

    Christ, this forum software sucks.

  • innocent bystander (unregistered) in reply to Oliver Klozoff
    Oliver Klozoff:
    Perhaps the desired word is 'titular'?
    I like tits.
  • BogusDude (unregistered) in reply to pbounaix
    pbounaix:

    <FONT size=2>regarding "attritioned" what dictionary are you referring to?</FONT>

    <FONT size=2></FONT> 

    <FONT size=2>- Websters online doesnt find it: </FONT><FONT size=2>http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=attritioned</FONT>

    <FONT size=2>- dictionary.com doesnt find it: </FONT><FONT size=2>http://dictionary.reference.com/search?q=attritioned</FONT>

    <FONT size=2>- Microsoft Word 2003 doesnt recognize it either</FONT>

    <FONT size=2></FONT> 

    [pi]<FONT size=2> :P</FONT>

    What's more, google's define: attritioned ability doesn't pick it up. I'm afraid the word doesn't exist. Sorry Alex.

  • gimblet (unregistered) in reply to pbounaix

    Atritted just about works for me.

    http://unabridged.merriam-webster.com/cgi-bin/unabridged?va=attrit&x=0&y=0

  • Coward (unregistered) in reply to Anonymous
    Anonymous:
    Putting the opening brace on its own line does nothing but reduce the amount of code you can see on your screen at once, forcing you to scroll more.


    Existence of your post in this page forced me to scroll more but I didn't mind.
  • BogusDude (unregistered)

    WTF is up with:

    if ((expansionRate) < 1 || (expansionRate) > 6)

    ????

    I think he/she meant: if ((expansionRate < 1) || (expansionRate > 6))

    While the extra braces won't change the meaning, if you WANT to use them, use them correctly.

    WhyTF didn't Jed fix it ?

  • (cs)
    Alex Papadimoulis:

    The "before" version ...

    /* Validate Arguments */
    if ((expansionRate) < 1 || (expansionRate) > 6)
      throw new ArgumentOutOfRangeException ("expansionRate","must be between 1 and 6 inclusive");
    if ( (expansionRate == 1) && (partCoefficient == 1) )
      throw new ArgumentException("if expansionRate is 1, partCoefficient cannot possibly be 1");
    //ED: Snip
    if (calcMod == null)
      throw new ArgumentNullException("calcMod");
    if ((threshold) <= 0 || (threshold) >= 1)
      throw new ArgumentOutOfRangeException("threshold","must be between 0 and 1");

    I'd suggest putting all error messages in a variable and then throwing an ArgumentException? This way the UI can decide whether to display only "Invalid arguments found" or dump all the errors. This is useful for UI programs, when the errors happen "near the surface" and don't have to be interpreted by other parts of the code.

    /* Validate Arguments */
    StringBuffer errorsFound = newStringBuffer();
    if ((expansionRate) < 1 || (expansionRate) > 6)
      errorsFound.append("ArgumentOutOfRangeException: expansionRate must be between 1 and 6 inclusive\r\n");
    if ( (expansionRate == 1) && (partCoefficient == 1) )
      errorsFound.append("ArgumentException : if expansionRate is 1, partCoefficient cannot possibly be 1\r\n");
    //ED: Snip
    if (calcMod == null)
      throw new ArgumentNullException("calcMod");
    if ((threshold) <= 0 || (threshold) >= 1)
      errorsFound.append("ArgumentOutOfRangeException: threshold must be between 0 and 1\r\n");
    
    if (errorsFound.length > 0)
      throw new ArgumentException(errorsFound);
    

    Kudos for breaking the MCV paradigm by adding visual formatting (break lines) in the controller code :) I always do it when concatenating several errors, so that when you display the whole exception in JSP, every error starts a new line. In other contexts, that would be wrong.

    You can also ask the user to copy/paste the error messages and send them to you, or ask him to read them over the phone.

  • (cs) in reply to Enric Naval

    forgot to change an exception there :P

    (I love [pi] too)

  • Sybren (unregistered)

    Am I the only one who thinks "(expansionRate)  < 1" has too many paretheses? Come on, use common sense and just write "expansionRate < 1"!

  • Chrid (unregistered) in reply to David Wolever

    'Attritioned' is a perfectly cromulent word.

  • (cs) in reply to Jenny Simonds
    Jenny Simonds:

    Has anyone ever published a survey on how many people code with the various curly brace styles?

    I use an old-school format which used to be popular in Windows-world, like this:

    {
    <font color="#008000">// snip</font>

    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename)); <font color="#0000ff">if</font> (szFilename[0])
    {
    eRet = ValidateFilename (szFilename);
    if (eRet==retOK)
    {<font color="#008000">// Process the file...</font> eRet = DoSomethingWithFile (szFilename); }

    return eRet;
    }
    

    }

    instead of the (inferior IMO :) BSD style:

    {
    <font color="#008000">// snip</font>
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <font color="#0000ff">if</font> (szFilename[0])<br>    {<br>        eRet = ValidateFilename (szFilename);<br>        if (eRet==retOK)<br>        {<font color="#008000">// Process the file...</font>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    or the (even worse) K&R style:

    {
    <font color="#008000">// snip</font>
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <font color="#0000ff">if</font> (szFilename[0])) {<br>        eRet = ValidateFilename (szFilename);<br>        if (eRet==retOK) {<br>            <font color="#008000">// Process the file...</font>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    My style is in a clear minority nowadays, judging by the code I've seen over the years, but I wonder just how minor it is.



    I used to use the third style in my notepad days.


    Now I'm using visual studio, it tends to automatically use the second form, so I don't fight it anymore...

  • zootm (unregistered) in reply to Quinnum
    Quinnum:


    Now I'm using visual studio, it tends to automatically use the second form, so I don't fight it anymore...


    Uncheck "Leave open braces on same line as construct" in Text Editor/C#/Formatting (or whatever language, I guess), and rejoin the dark side.

    I would never put a comment on the same line as an open brace though, that example looks a bit weird to me.

  • (cs) in reply to Jenny Simonds
    Jenny Simonds:

    Has anyone ever published a survey on how many people code with the various curly brace styles?

    I use an old-school format which used to be popular in Windows-world, like this:

    {
    <font color="#008000">// snip</font>

    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename)); <font color="#0000ff">if</font> (szFilename[0])
    {
    eRet = ValidateFilename (szFilename);
    if (eRet==retOK)
    {<font color="#008000">// Process the file...</font> eRet = DoSomethingWithFile (szFilename); }

    return eRet;
    }
    

    }

    instead of the (inferior IMO :) BSD style:

    {
    <font color="#008000">// snip</font>
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <font color="#0000ff">if</font> (szFilename[0])<br>    {<br>        eRet = ValidateFilename (szFilename);<br>        if (eRet==retOK)<br>        {<font color="#008000">// Process the file...</font>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    or the (even worse) K&R style:

    {
    <font color="#008000">// snip</font>
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <font color="#0000ff">if</font> (szFilename[0])) {<br>        eRet = ValidateFilename (szFilename);<br>        if (eRet==retOK) {<br>            <font color="#008000">// Process the file...</font>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    My style is in a clear minority nowadays, judging by the code I've seen over the years, but I wonder just how minor it is.




    I mostly use the third style. But I'm not religious about it, the second style is also OK for me; I would not even care about a mix of 2nd and 3rd style. The first style obviously conflicts with the other two.
    My reason for the 3rd style is that it is somehow consistent with other (not C-style languages), where you write

    if length(szFilename)>0 then
      eRet := ValiddateFilename(szFilename);
      if eRet = retOK then
        eRet := DoSomethingWithFile(szFilename);
      end if;
      return eRet;
    end if;

  • (cs) in reply to Chrid

    Anonymous:
    'Attritioned' is a perfectly cromulent word.

    nonsense - n., 1. flerping gorphazzle xawdrico. 2. the multiplication of xylophone and obstinative reactivation, especially tilted opposition.

    (or in the same style:    recursive - adj., see recursive )

  • El Anonymoso (unregistered) in reply to ammoQ

    Yes, I use the third style whenever I use C or any other brace-delimited language because it looks nicer to my python-addled brain. Long live the whitespace, and may all your list comprehensions be fruitful!

  • Metadeos (unregistered) in reply to Ciaran

    Anyone here, who can tell me, what goes through

    Alex Papadimoulis:


    if ((threshold) <= 0 || (threshold) >= 1)
    throw new ArgumentOutOfRangeException("threshold","must be between 0 and 1")

    or

    if ((threshold) <= 0 || (threshold) >= 1) invalidArgs ++;


    ?
    So validation by Jed's Code at least raises the rate of accepted input above 0, one real improvement 8-)

  • (cs) in reply to ammoQ
    ammoQ:
    Jenny Simonds:

    Has anyone ever published a survey on how many people code with the various curly brace styles?

    I use an old-school format which used to be popular in Windows-world, like this:

    {
    <font color="#008000">// snip</font>

    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename)); <font color="#0000ff">if</font> (szFilename[0])
    {
    eRet = ValidateFilename (szFilename);
    if (eRet==retOK)
    {<font color="#008000">// Process the file...</font> eRet = DoSomethingWithFile (szFilename); }

    return eRet;
    }
    

    }

    instead of the (inferior IMO :) BSD style:

    {
    <font color="#008000">// snip</font>
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <font color="#0000ff">if</font> (szFilename[0])<br>    {<br>        eRet = ValidateFilename (szFilename);<br>        if (eRet==retOK)<br>        {<font color="#008000">// Process the file...</font>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    or the (even worse) K&R style:

    {
    <font color="#008000">// snip</font>
    m_oEDFilename.GetWindowText (szFilename, sizeof(szFilename));
    <font color="#0000ff">if</font> (szFilename[0])) {<br>        eRet = ValidateFilename (szFilename);<br>        if (eRet==retOK) {<br>            <font color="#008000">// Process the file...</font>
            eRet = DoSomethingWithFile (szFilename);
        }
        
    return eRet;
    }
    

    }

    My style is in a clear minority nowadays, judging by the code I've seen over the years, but I wonder just how minor it is.




    I mostly use the third style. But I'm not religious about it, the second style is also OK for me; I would not even care about a mix of 2nd and 3rd style. The first style obviously conflicts with the other two.
    My reason for the 3rd style is that it is somehow consistent with other (not C-style languages), where you write

    if length(szFilename)>0 then
      eRet := ValiddateFilename(szFilename);
      if eRet = retOK then
        eRet := DoSomethingWithFile(szFilename);
      end if;
      return eRet;
    end if;


    Every few months I flip toggle between BSD and K&R style.  I like the fact that K&R conserves my verticle real estate more.  To some extent, the more code I can see on screen without scrolling the better.  This theory is only valid in moderation, since too little verticle whitespace will kill readability even faster than too much...

    To this end I also use the ternary operator for certain simple operations.  For instance, I write a lot of code against an API that takes an array of objects.  I'll use this idiom quite a bit...

    if (logger.isDebug() {
        logger.debug("Param0: " + (null == args[0])?"[null]":args[0].toString());
        logger.debug("Param1: " + (null == args[1])?"[null]":args[1].toString());
        logger.debug("Param2: " + (null == args[2])?"[null]":args[2].toString());
    }

    I don't believe that the ternary operator here degrades readability, especially since it is an idiom that a reuse frequently.

    On the other hand, BSD style is nice because I can manipulate the body of a block seperately from a control statement.  This is useful while debugging.  I can, for instance, comment out the while() control statement with a simple line comment and force the body of the while loop to run once.

  • (cs) in reply to Metadeos
    Anonymous:
    Anyone here, who can tell me, what goes through
    Alex Papadimoulis:


    if ((threshold) <= 0 || (threshold) >= 1)
    throw new ArgumentOutOfRangeException("threshold","must be between 0 and 1")

    or

    if ((threshold) <= 0 || (threshold) >= 1) invalidArgs ++;


    ?
    So validation by Jed's Code at least raises the rate of accepted input above 0, one real improvement 8-)



    threshold is probably a floating point number with 0<=threshold<1
  • (cs)

    <FONT face="Courier New" size=2>aww.  i find of feel sorry the old dinosaur.  "exceptions?  why throw twelve when you can just throw one?"</FONT>

Leave a comment on “Argument About Argument Validation”

Log In or post as a guest

Replying to comment #:

« Return to Article