Another style question

Discussion in 'C Programming' started by Christopher Benson-Manica, Feb 4, 2004.

  1. How about your if/else if/else constructs? Being nitpicky like any
    good C programmer, I'm in the process of transforming code written
    like

    if( cond ) {
    ...
    } else
    if( some_other_cond ) {
    ...
    } else
    if( explode_with_pretty_colors) {
    /* explode with pretty colors */
    }
    else {
    ...
    }

    to my preferred style:

    if( cond ) {
    ...
    }
    else if( some_other_cond ) {
    ...
    }
    else if( explode_with_pretty_colors ) {
    /* explode! */
    }
    else {
    ...
    }

    Another possibility (I don't use it in C) is

    if( cond ) {
    ...
    } else if( blah ) {
    ...
    }
    ....

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Feb 4, 2004
    #1
    1. Advertising

  2. Christopher Benson-Manica <> scribbled the following:
    > How about your if/else if/else constructs? Being nitpicky like any
    > good C programmer, I'm in the process of transforming code written
    > like


    > if( cond ) {
    > ...
    > } else
    > if( some_other_cond ) {
    > ...
    > } else
    > if( explode_with_pretty_colors) {
    > /* explode with pretty colors */
    > }
    > else {
    > ...
    > }


    > to my preferred style:


    > if( cond ) {
    > ...
    > }
    > else if( some_other_cond ) {
    > ...
    > }
    > else if( explode_with_pretty_colors ) {
    > /* explode! */
    > }
    > else {
    > ...
    > }


    Make those if( cond ) thingies if (cond), and you've got my style
    pretty much spot-on.

    > Another possibility (I don't use it in C) is


    > if( cond ) {
    > ...
    > } else if( blah ) {
    > ...
    > }
    > ...


    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "'So called' means: 'There is a long explanation for this, but I have no
    time to explain it here.'"
    - JIPsoft
    Joona I Palaste, Feb 4, 2004
    #2
    1. Advertising

  3. Christopher Benson-Manica wrote:

    > How about your if/else if/else constructs?
    > Being [anal] like any good C programmer,
    > I'm in the process of transforming code written like


    [snip]

    I prefer:

    if (cond) {
    ...
    }
    else
    if (some_other_cond) {
    ...
    }
    else
    if(explode_with_pretty_colors) {
    /* explode with pretty colors */
    }
    else {
    ...
    }

    But like I said
    Get a C reformatter program like indent:

    http://www.gnu.org/software/indent/indent.html

    so that you can convert
    from one format to another automatically.
    E. Robert Tisdale, Feb 4, 2004
    #3
  4. "Christopher Benson-Manica" <> wrote in message
    news:bvrh8d$731$...
    > How about your if/else if/else constructs? Being nitpicky like any
    > good C programmer, I'm in the process of transforming code [...]


    Why do you need to transform code from one style to another? If you use
    any source-control system, it may lead to too many differences that aren't.

    FWIW, my prefered style is similar to yours, except that I use:

    if (cond)
    {
    ...
    }
    else if (some_other_cond)
    {
    ...
    }
    else
    {
    ...
    }

    The opening brace sits on its own line, just like the closing one, and the
    two indent the same. There is a space before the opening parenthesis and
    voluntary space after the closing one, but never the other way round. Now,
    this is The Only True Style, so stick to it! :)

    Peter
    Peter Pichler, Feb 4, 2004
    #4
  5. Joona I Palaste <> spoke thus:

    > Make those if( cond ) thingies if (cond), and you've got my style
    > pretty much spot-on.


    That's a house rule. If I were a style Nazi I would have committed
    seppuku my first week ;)

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Feb 4, 2004
    #5
  6. Christopher Benson-Manica

    Ed Morton Guest

    Christopher Benson-Manica wrote:

    > How about your if/else if/else constructs? Being nitpicky like any
    > good C programmer, I'm in the process of transforming code written
    > like

    <snip>>
    > to my preferred style:

    <snip>
    > Another possibility (I don't use it in C) is
    >
    > if( cond ) {
    > ...
    > } else if( blah ) {
    > ...
    > }
    > ...
    >


    If you're going for consistency, why not just run all your code through
    a C beautifier and just accept whatever it spits out? As long as all the
    code's consistent in style, the actual style selected doesn't matter a
    whole lot.

    FWIW the UNIX tool "cb -s" (K&R mode) spits out your boss's preferred
    style for case statements and the final style above for if...else.
    Without the "-s" it still prefers your boss's case style but doesn't
    appear to do anything useful with "if...else".

    Ed.
    Ed Morton, Feb 4, 2004
    #6
  7. Peter Pichler <> spoke thus:

    > Why do you need to transform code from one style to another? If you use
    > any source-control system, it may lead to too many differences that aren't.


    Well, there is that, of course, but I figure that since MY style is
    the "One Style," it's justified. One style to rule them all...

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Feb 4, 2004
    #7
  8. Christopher Benson-Manica <> scribbled the following:
    > Joona I Palaste <> spoke thus:
    >> Make those if( cond ) thingies if (cond), and you've got my style
    >> pretty much spot-on.


    > That's a house rule. If I were a style Nazi I would have committed
    > seppuku my first week ;)


    Can you please ask whoever came up with that rule what they were
    smoking? =)

    Personally I'm a bit of a style Nazi myself. Whenever I have to edit
    code someone else wrote, I take time to format it to "readable" style
    first. Which means:
    - Indents are 2 spaces
    - Braces K&R style: opening brace on the same line, closing on its own
    line, one space before the opening brace
    - Always 1 space after every comma and every semicolon, otherwise
    1 space around every "important" operator or no spaces at all if it's
    not "important"
    - Always 1 space between *keywords* (if, for, while, etc) and the
    opening paren, never any space between a function or a macro name and
    the opening paren
    - Two blank lines between each function, one blank line separating
    conceptual groups of statements
    That's pretty much the important stuff.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "Normal is what everyone else is, and you're not."
    - Dr. Tolian Soran
    Joona I Palaste, Feb 4, 2004
    #8
  9. Ed Morton <> scribbled the following:
    > If you're going for consistency, why not just run all your code through
    > a C beautifier and just accept whatever it spits out? As long as all the
    > code's consistent in style, the actual style selected doesn't matter a
    > whole lot.


    > FWIW the UNIX tool "cb -s" (K&R mode) spits out your boss's preferred
    > style for case statements and the final style above for if...else.
    > Without the "-s" it still prefers your boss's case style but doesn't
    > appear to do anything useful with "if...else".


    Can the C beautifier also beautify Java?

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "I am lying."
    - Anon
    Joona I Palaste, Feb 4, 2004
    #9
  10. Joona I Palaste <> spoke thus:

    > Can you please ask whoever came up with that rule what they were
    > smoking? =)


    Will do! :)

    > - Indents are 2 spaces


    Ours are five. I count on the pain to wake me up on Monday morning.
    It isn't as bad as our <ot>HTML, however - indentation is essentially
    random, making editing tables and scripts a joy. I've spent several
    days just reformatting it, never mind fixing actual errors...</ot>

    > - Braces K&R style: opening brace on the same line, closing on its own
    > line, one space before the opening brace


    I'm a former separate-line'r who's been beaten into submission...

    > - Two blank lines between each function, one blank line separating
    > conceptual groups of statements


    That's another bad thing - there is space between initial declarations
    and code, but blank lines elsewhere within functions are frowned upon.
    Heavens knows why...

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Feb 4, 2004
    #10
  11. Christopher Benson-Manica

    Ed Morton Guest

    Joona I Palaste wrote:

    > Ed Morton <> scribbled the following:
    >
    >>If you're going for consistency, why not just run all your code through
    >>a C beautifier and just accept whatever it spits out? As long as all the
    >>code's consistent in style, the actual style selected doesn't matter a
    >>whole lot.

    >
    >
    >>FWIW the UNIX tool "cb -s" (K&R mode) spits out your boss's preferred
    >>style for case statements and the final style above for if...else.
    >>Without the "-s" it still prefers your boss's case style but doesn't
    >>appear to do anything useful with "if...else".

    >
    >
    > Can the C beautifier also beautify Java?
    >


    Maybe, but I wouldn't trust cb with Java or even C++. There are plenty
    of beautifiers for those and other languages out there though, e.g. take
    a look at
    http://ldp.homegrownhost.net/HOWTO/C-C Beautifier-HOWTO/beautifier_for_others.html

    Ed.
    Ed Morton, Feb 4, 2004
    #11
  12. Ed Morton wrote:

    > Joona I Palaste wrote:
    >
    >> Can the C beautifier also beautify Java?

    >
    > Maybe, but I wouldn't trust cb with Java or even C++.
    > There are plenty of beautifiers
    > for those and other languages out there though, e.g. take a look at


    > http://ldp.homegrownhost.net/HOWTO/C-C Beautifier-HOWTO/beautifier_for_others.html


    BEWARE!

    Code "beautifiers" are not necessarily [style] reformatters.
    Most beautifiers insert text and embedded printer control sequences
    that your compiler will *not* accept.

    You also need to verify that
    reformatting did not change the meaning of your code.
    Always compile both the original and the reformatted versions
    of your code and verify that the resulting objects are identical.
    E. Robert Tisdale, Feb 4, 2004
    #12
  13. Joona I Palaste wrote:

    > Can you please ask whoever came up with that rule what they were
    > smoking? =)
    >
    > Personally I'm a bit of a style Nazi myself. Whenever I have to edit
    > code someone else wrote, I take time to format it to "readable" style
    > first. Which means:
    > - Indents are 2 spaces
    > - Braces K&R style: opening brace on the same line, closing on its own
    > line, one space before the opening brace
    > - Always 1 space after every comma and every semicolon, otherwise
    > 1 space around every "important" operator or no spaces at all if it's
    > not "important"
    > - Always 1 space between *keywords* (if, for, while, etc) and the
    > opening paren, never any space between a function or a macro name and
    > the opening paren
    > - Two blank lines between each function, one blank line separating
    > conceptual groups of statements
    > That's pretty much the important stuff.


    Say what you will, but the above are not very important elements in
    determining whether a style is good or bad. Some are more important
    than other. I would say spaces around most operators is a good thing.

    But in general, as long as layout style is consistent and somewhat
    reasonable, naming and commenting conventions are more important.
    As are conventions for when to use and not to use macros.

    If you find code much harder to read because the opening brace of
    a block is on its own line instead of K&R style, then it is not
    the code that has a problem.

    1. while(condition) {
    condition = important();
    }

    2. while ( condition )
    {
    condition = important();
    }

    Point is, 1 vs 2 should be hardly an issue. If you are someone who uses
    1 and must work for some people who demand 2 then I don't see that you
    have a problem at all.

    I use neither of the above, but if someone gave me some reason for why
    I should use 1 or 2 I would not have a problem doing that.

    I think I would object if someone told me to code like this though:
    a=b+c*3;
    I think a = b + c * 3; is much better. There is even a physiological
    reason for this. I think it is called crowding. It basically means that
    human eyes have an easier time distuinguishing objects which are further
    apart than close together. So there, I have a non-emotional,
    non-subjective reason for this particular style choice. Which means I
    win ;)


    --
    Thomas.
    Thomas Stegen CES2000, Feb 4, 2004
    #13
  14. Thomas Stegen CES2000 wrote:

    > Joona I Palaste wrote:
    >
    > I think I would object if someone told me to code like this though:
    > a=b+c*3;
    > I think a = b + c * 3; is much better.


    And I prefer

    a = c * 3 + b;

    YMMV.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
    Richard Heathfield, Feb 4, 2004
    #14
  15. Christopher Benson-Manica

    CBFalconer Guest

    Christopher Benson-Manica wrote:
    > Joona I Palaste <> spoke thus:
    >
    > > Make those if( cond ) thingies if (cond), and you've got my style
    > > pretty much spot-on.

    >
    > That's a house rule. If I were a style Nazi I would have committed
    > seppuku my first week ;)


    My argument is that if is not a function, and thus should have a
    following blank. If you want blanks surrounding "cond" be my
    guest. I want to easily distinguish function calls from other
    constructs. Richard Heathfield disagrees.

    So, which is the house rule?

    BTW, a useful style rule is that the else clause is the longer
    one, other things being equal. This makes finding the controlling
    statements easier. Contrast:

    if (foo) {
    ....
    ....
    }
    else {
    /* notmuch */
    bar();
    }

    with
    if (notfoo) {
    /* notmuch */
    bar();
    }
    else {
    ....
    ....
    }

    finding a controlling statment for something in the else clause
    involves first finding the else, and then continuing north. The
    second phase is much easier with the short then clause. In the
    extreme, when applied to else if clauses, you get:

    if (foo) foof();
    else if (bar) barf();
    else if (goo) goof();
    else {
    moo();
    gou();
    gai();
    pan();
    }

    All of this is all very well when you are developing your style.
    However once you have something, be consistent, at least through
    any single source file. Try things out and see what minimizes the
    errors and maximizes the readability.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Feb 4, 2004
    #15
  16. Christopher Benson-Manica

    CBFalconer Guest

    Joona I Palaste wrote:
    >

    .... snip ...
    >
    > Personally I'm a bit of a style Nazi myself. Whenever I have to edit
    > code someone else wrote, I take time to format it to "readable" style
    > first. Which means:
    > - Indents are 2 spaces
    > - Braces K&R style: opening brace on the same line, closing on its
    > own line, one space before the opening brace
    > - Always 1 space after every comma and every semicolon, otherwise
    > 1 space around every "important" operator or no spaces at all if
    > it's not "important"
    > - Always 1 space between *keywords* (if, for, while, etc) and the
    > opening paren, never any space between a function or a macro name
    > and the opening paren
    > - Two blank lines between each function, one blank line separating
    > conceptual groups of statements
    > That's pretty much the important stuff.


    I think we are pretty close to agreement. Try the following for
    indent.pro. It is not perfect, but comes as close as I have found
    possible to my style.

    -kr -l66 -i3 -bad -di16 -lc66 -nce -ncs -cbi0 -bbo -pmt -psl -ts1

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Feb 4, 2004
    #16
  17. Christopher Benson-Manica

    CBFalconer Guest

    "E. Robert Tisdale" wrote:
    > Christopher Benson-Manica wrote:
    >
    > > How about your if/else if/else constructs?
    > > Being [anal] like any good C programmer,

    ^^^^^^
    This is another of Trollsdales gratuitious alterations of quotes.
    He is sneaky, very sneaky.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Feb 4, 2004
    #17
  18. Christopher Benson-Manica

    CBFalconer Guest

    Richard Heathfield wrote:
    > Thomas Stegen CES2000 wrote:
    > > Joona I Palaste wrote:
    > >
    > > I think I would object if someone told me to code like this though:
    > > a=b+c*3;
    > > I think a = b + c * 3; is much better.

    >
    > And I prefer
    >
    > a = c * 3 + b;
    >
    > YMMV.


    Definitely MV. I can even find cases where I want different
    emphasis, and would write:

    a = 3*c + b;
    or
    dsq = b*b - 4*a*c;

    although normally I would not suppress the blanks.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Feb 5, 2004
    #18
  19. CBFalconer <> spoke thus:

    > So, which is the house rule?


    Both - the if( and the ( cond ). Our editor even auto-formats like
    this.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Feb 5, 2004
    #19
  20. CBFalconer <> scribbled the following:
    > "E. Robert Tisdale" wrote:
    >> Christopher Benson-Manica wrote:
    >> > How about your if/else if/else constructs?
    >> > Being [anal] like any good C programmer,

    > ^^^^^^
    > This is another of Trollsdales gratuitious alterations of quotes.
    > He is sneaky, very sneaky.


    Christopher originally wrote "nitpicky", not "anal". It's fun to see
    what Trollsdale will alter *my* message to. =)

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "I will never display my bum in public again."
    - Homer Simpson
    Joona I Palaste, Feb 5, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rob Nicholson
    Replies:
    3
    Views:
    668
    Rob Nicholson
    May 28, 2005
  2. Replies:
    1
    Views:
    780
    Bertilo Wennergren
    Nov 24, 2003
  3. Christopher Benson-Manica

    Yet another nitpicky style question

    Christopher Benson-Manica, Feb 13, 2004, in forum: C Programming
    Replies:
    17
    Views:
    504
    Leor Zolman
    Feb 20, 2004
  4. Replies:
    3
    Views:
    229
    Nick Keighley
    Mar 17, 2010
  5. Ken Varn
    Replies:
    0
    Views:
    428
    Ken Varn
    Apr 26, 2004
Loading...

Share This Page