matching { } syntax style

Discussion in 'C++' started by bart, Oct 10, 2003.

  1. bart

    bart Guest

    Why is it that everybody likes the follwowing curly braces syntax

    function() {
    implementations;
    }

    I find the following much better to read (C style)

    function()
    {
    implementations;
    }

    kind regards,
    Bart
    bart, Oct 10, 2003
    #1
    1. Advertising

  2. bart

    Phlip Guest

    > Why is it that everybody likes the follwowing curly braces syntax
    >
    > function() {
    > implementations;
    > }


    They don't. Some like it and some don't.

    > I find the following much better to read (C style)
    >
    > function()
    > {
    > implementations;
    > }


    For style, I follow the ultimate acknowledge reference for English - /The
    Elements of Style/.

    It says to use parallel construction on parallel concepts.

    Don't say, "The big red lion lay down with the lamb, small and furry".

    Say, "The big red lion lay down with the small furry lamb."

    The adjectives parallel their relation to their noun.

    So, in programming, put the curly braces where they parallel each other.

    --
    Phlip
    Phlip, Oct 10, 2003
    #2
    1. Advertising

  3. bart

    jeffc Guest

    "bart" <> wrote in message
    news:3f86b7e8$0$58711$4all.nl...
    > Why is it that everybody likes the follwowing curly braces syntax
    >
    > function() {
    > implementations;
    > }
    >
    > I find the following much better to read (C style)
    >
    > function()
    > {
    > implementations;
    > }


    I don't think everybody does like the former. I think at least half the
    people prefer the latter.
    jeffc, Oct 10, 2003
    #3
  4. bart

    Ron Natalie Guest

    "bart" <> wrote in message news:3f86b7e8$0$58711$4all.nl...
    > Why is it that everybody likes the follwowing curly braces syntax
    >
    > function() {
    > implementations;
    > }
    >
    > I find the following much better to read (C style)
    >
    > function()
    > {
    > implementations;
    > }
    >

    What makes you think the latter is C style? And what makes you think it's
    easier to read?
    Ron Natalie, Oct 10, 2003
    #4
  5. bart

    Tim Clacy Guest

    bart wrote:
    > Why is it that everybody likes the follwowing curly braces syntax
    >
    > function() {
    > implementations;
    > }
    >
    > I find the following much better to read (C style)
    >
    > function()
    > {
    > implementations;
    > }
    >
    > kind regards,
    > Bart


    Some of us don't like either; they're there to make compiler writers lives
    easier, not ours.
    Tim Clacy, Oct 10, 2003
    #5
  6. While it was 10/10/03 2:50 pm throughout the UK, bart sprinkled little
    black dots on a white screen, and they fell thus:
    > Why is it that everybody likes the follwowing curly braces syntax
    >
    > function() {
    > implementations;
    > }


    I'm one of everybody, amn't I? I personally hate it when people can't
    be bothered to indent.

    > I find the following much better to read (C style)
    >
    > function()
    > {
    > implementations;
    > }


    Well, I guess that

    function() {
    implementations;
    }

    gives the best of both worlds. :)

    Stewart.

    --
    My e-mail is valid but not my primary mailbox. Please keep replies on
    on the 'group where everyone may benefit.
    Stewart Gordon, Oct 10, 2003
    #6
  7. Hi bart,

    > function() {
    > implementations;
    > }


    This style has a very big advantage when you use a single-line debugger, In
    fact not for a function. Try an if instead.

    When you use these two cases with a single-line debugger...

    if (someboolexpression)
    dosomething;

    if (someboolexpression) {
    dosomethingmore;
    }

    ...and the line with an if appears the curly brace tells you that a block is
    following. If not one single command follows.

    > function()
    > {
    > implementations;
    > }


    I personally like this style more. In my opinion it is more readable. But I
    do not use a single-line debugger. So I assume that I am not part of
    "everybody".

    Regards,
    Patrick
    Patrick Kowalzick, Oct 10, 2003
    #7
  8. bart wrote:

    > Why is it that everybody likes the follwowing curly braces syntax
    >
    > function() {
    > implementations;
    > }
    >
    > I find the following much better to read (C style)
    >
    > function()
    > {
    > implementations;
    > }
    >
    > kind regards,
    > Bart
    >
    >


    Some people like this style:
    return_type
    function()
    {
    implementation;
    }
    The braces show the indentation.

    I prefer to have the braces line up to help show the indentation
    levels.

    But this is what they call a religious issue; there is no
    correct answer, only what people believe.

    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c -faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.raos.demon.uk/acllc-c /faq.html
    Other sites:
    http://www.josuttis.com -- C++ STL Library book
    Thomas Matthews, Oct 10, 2003
    #8
  9. bart

    Tim Clacy Guest

    Tim Clacy wrote:
    > bart wrote:
    >> Why is it that everybody likes the follwowing curly braces syntax
    >>
    >> function() {
    >> implementations;
    >> }
    >>
    >> I find the following much better to read (C style)
    >>
    >> function()
    >> {
    >> implementations;
    >> }
    >>
    >> kind regards,
    >> Bart

    >
    > Some of us don't like either; they're there to make compiler writers
    > lives easier, not ours.


    ....and just to set the cat amongst the pigeons, I'm quite fond of this:

    void fn() {
    while (...) {
    switch (...) {
    case :
    case :
    default : } } }

    :)
    Tim Clacy, Oct 10, 2003
    #9
  10. bart

    Default User Guest

    bart wrote:
    >
    > Why is it that everybody likes the follwowing curly braces syntax
    >
    > function() {
    > implementations;
    > }
    >
    > I find the following much better to read (C style)


    If anything, the former is C-style, as it was used by the originators of
    C in K&R. Often refered to as K&R style or OTBS (one true brace style).

    >
    > function()
    > {
    > implementations;
    > }



    I have a preference for Whitesmith's style:

    if (1)
    {
    std::cout << "code!\n";
    }


    Just pick a style and use it consistently.



    Brian Rodenborn
    Default User, Oct 10, 2003
    #10
  11. bart

    Kris Wempa Guest

    "bart" <> wrote in message
    news:3f86b7e8$0$58711$4all.nl...
    > Why is it that everybody likes the follwowing curly braces syntax
    >
    > function() {
    > implementations;
    > }
    >
    > I find the following much better to read (C style)
    >
    > function()
    > {
    > implementations;
    > }
    >
    > kind regards,
    > Bart
    >


    I prefer your second style in functions only. If statement blocks like I
    prefer to use the first. I just don't see the point in dedicating an ENTIRE
    line to a measly '{'. I'd much rather write:

    if (x == 10) {

    }

    than:

    if (x == 10)
    {

    }

    As long as my closing '}' is lined up DIRECTLY under the statement that
    opened it, I find it easy to read.
    Kris Wempa, Oct 10, 2003
    #11
  12. bart

    Howard Guest


    >... And what makes you think it's easier to read?


    Umm...the fact that *he* finds it easier to read, perhaps? (Does an opinion
    need a reason?) And I agree. For some reason (i have no idea why), I find
    it much easier to quickly spot braces that are aligned vertically than a
    closing brace matching the start of a line of text. So, for me, it's easier
    to read.

    On the other hand, my boss, who wrote the code I'm updating and maintaining,
    likes it the other way. Must be why he's the boss. :)

    -Howard
    Howard, Oct 10, 2003
    #12
  13. bart

    lilburne Guest

    bart wrote:

    > Why is it that everybody likes the follwowing curly braces syntax
    >
    > function() {
    > implementations;
    > }
    >
    > I find the following much better to read (C style)
    >
    > function()
    > {
    > implementations;
    > }
    >


    Pick a style any style and stick to it. Personally I prefer

    function()
    {
    if (expression) {
    statements;
    }
    }

    but that is because it is our house style. Prior to my
    current place I preferred another style, it doesn't matter a
    jot, which you use. But if you are programming with others a
    standard style is a great help. I can look over any piece of
    code in the company and the layout is the same, it looks my
    code, and my code looks like anyone else's. The standard
    layout helps you to understand what is happening.
    Occasionally we receive code from some outside source that
    does not conform to our standard, and it is always
    difficult to read. That doesn't mean that it is wrong, or a
    bad style, its just that it isn't the one we are used to.
    lilburne, Oct 10, 2003
    #13
  14. bart

    J. Campbell Guest

    "bart" <> wrote in message news:<3f86b7e8$0$58711$4all.nl>...
    > Why is it that everybody likes the follwowing curly braces syntax
    >
    > function() {
    > implementations;
    > }
    >
    > I find the following much better to read (C style)
    >
    > function()
    > {
    > implementations;
    > }
    >
    > kind regards,
    > Bart


    Bart...I agree with the others. It's a matter of preference. I'm
    pretty new to C++, and as I was getting started, I read several essays
    on styles. I ended up using Bruce Eckel's book's style. eg:

    function(){
    implementations;
    }

    I like this style because:
    1) it takes up less space, vertically.
    2) you read the function name, immediately see the open bracket, and
    then look down to where the scope for that indentation ends.

    My one minor exception to that I sometimes adopt is for if else
    statements:

    function(){
    if(expression){
    statement1;
    statement2;
    }else{
    statement1;
    statement2;
    }
    }

    However, I also sometimes do single line if else if it fits nicely
    onto one line.

    function(){
    if(expression) statement; else statement;
    }
    J. Campbell, Oct 11, 2003
    #14
  15. bart

    Phlip Guest

    Tim Clacy wrote:

    > ...and just to set the cat amongst the pigeons, I'm quite fond of this:
    >
    > void fn() {
    > while (...) {
    > switch (...) {
    > case :
    > case :
    > default : } } }
    >
    > :)


    I'm fond of very short functions, and replacing switch statements with
    virtual messages, so my bad-ass pidgeon is not alarmed by your silly
    little cat.

    --
    Phlip
    Phlip, Oct 11, 2003
    #15
  16. bart

    Clive Guest

    "J. Campbell" <> wrote in message
    news:...
    <snip>
    < However, I also sometimes do single line if else if it fits nicely
    < onto one line.
    <
    < function(){
    < if(expression) statement; else statement;
    < }

    I don't meant to be fickle (I think this is the first occasion of me using
    that word :)
    but if your expression and statements fit nicely on a single line, wouldn't
    you be better off writing

    expression ? true_statement : false_statement;

    That way, you dont have to write if, any brackets, an extra ; and the else.
    Clive, Oct 11, 2003
    #16
  17. bart

    lilburne Guest

    Clive wrote:

    > "J. Campbell" <> wrote in message
    > news:...
    > <snip>
    > < However, I also sometimes do single line if else if it fits nicely
    > < onto one line.
    > <
    > < function(){
    > < if(expression) statement; else statement;
    > < }
    >
    > I don't meant to be fickle (I think this is the first occasion of me using
    > that word :)
    > but if your expression and statements fit nicely on a single line, wouldn't
    > you be better off writing
    >
    > expression ? true_statement : false_statement;
    >
    > That way, you dont have to write if, any brackets, an extra ; and the else.
    >
    >


    The problem with both of these 'styles' is that you can't
    put a simple breakpoint on any of the statements. The best
    you can do is put a conditional breakpoint (based on
    expression) on the line and then single step the expression.

    With the tertiary expression both true_statement and
    false_statement also have to be type compatible.
    lilburne, Oct 11, 2003
    #17
  18. bart

    Tim Clacy Guest

    Phlip wrote:
    > Tim Clacy wrote:
    >
    >> ...and just to set the cat amongst the pigeons, I'm quite fond of
    >> this:
    >>
    >> void fn() {
    >> while (...) {
    >> switch (...) {
    >> case :
    >> case :
    >> default : } } }
    >>
    >> :)

    >
    > I'm fond of very short functions, and replacing switch statements with
    > virtual messages, so my bad-ass pidgeon is not alarmed by your silly
    > little cat.


    The shorter the function, the more the relative waste of space the braces
    become; so where so you put your braces in your 'very short functions'? How
    about:

    struct A {
    virtual void fn0() { ... }
    virtual void fn1() { ... }
    virtual void fn2() { ... } };
    Tim Clacy, Oct 13, 2003
    #18
  19. "Clive" <> wrote in message
    news:bm9ehs$njq$...
    >
    > I don't meant to be fickle (I think this is the first occasion of me using
    > that word :)
    > but if your expression and statements fit nicely on a single line,

    wouldn't
    > you be better off writing
    >
    > expression ? true_statement : false_statement;


    Statements are not allowed in expressions. You cannot
    write, for instance ...

    someFlag ? continue : break;

    Also, if you used the syntactically correct form of...

    expression ? true_expression : false_expression;

    .... instead, it still must also be semantically correct so
    that the types returned by the sub-expressions are
    assignable to a common type (which then becomes the
    type of the entire expression). This, for instance,
    would be syntactically correct, but semantically illegal:

    someFlag ? 123 : "";

    IMO, it is always better to use the if(){}else{} instead
    of the ?: operator in all contexts that allow a statement,
    and use the conditional operator only when the context
    *requires* (rather than just *allows*) an expression.

    Cheers!

    - Risto -
    Risto Lankinen, Oct 13, 2003
    #19
  20. While it was 13/10/03 10:15 am throughout the UK, Risto Lankinen
    sprinkled little black dots on a white screen, and they fell thus:
    <snip>
    > This, for instance, would be syntactically correct, but semantically illegal:
    >
    > someFlag ? 123 : "";


    But I've just tried

    someFlag ? (void) 123 : (void) "";

    and gcc/g++ accepts it.

    > IMO, it is always better to use the if(){}else{} instead
    > of the ?: operator in all contexts that allow a statement,
    > and use the conditional operator only when the context
    > *requires* (rather than just *allows*) an expression.


    Guess you're kind of right there.

    But, which do most people prefer:

    if(qwert > 100) {
    yuiop = 50;
    } else {
    yuiop = 25;
    }

    or

    yuiop = (qwert > 100) ? 50 : 25;

    or even

    yuiop = ((qwert > 100) + 1) * 25;

    ....?

    Stewart.

    --
    My e-mail is valid but not my primary mailbox. Please keep replies on
    on the 'group where everyone may benefit.
    Stewart Gordon, Oct 13, 2003
    #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. Calum MacLean
    Replies:
    4
    Views:
    1,186
    Calum MacLean
    Jul 8, 2004
  2. Ulrich Scholz
    Replies:
    8
    Views:
    630
    Ulrich Scholz
    Aug 27, 2007
  3. Ken Varn
    Replies:
    0
    Views:
    443
    Ken Varn
    Apr 26, 2004
  4. Marc Bissonnette

    Pattern matching : not matching problem

    Marc Bissonnette, Jan 8, 2004, in forum: Perl Misc
    Replies:
    9
    Views:
    233
    Marc Bissonnette
    Jan 13, 2004
  5. Bobby Chamness
    Replies:
    2
    Views:
    226
    Xicheng Jia
    May 3, 2007
Loading...

Share This Page