style question

Discussion in 'C++' started by Torsten Mueller, Aug 7, 2008.

  1. Where does it come from to make spaces everywhere but not between a
    keyword and a condition? I'm confronted with code looking like that:

    if( x == 3 && y == 7 && z == 1024 )
    {
    for( int i = 0; i < 1000 ; i++ )
    {
    }
    }

    It's a company style guide convention. I would write it like this:

    if (x==3 && y==7 && z==1024)
    {
    for (int i=0; i<1000 ; i++)
    {
    }
    }

    I find this much more readable.

    The style guide also forbids to make a space in method declarations or
    definitions:

    class MyClass
    {
    void MyMethod(int param);
    }; ^ no space!

    void MyClass::MyMethod(int param)
    { ^ no space!
    }

    Is there any serious reason for this? Is this .NET or what??

    T.M.
    Torsten Mueller, Aug 7, 2008
    #1
    1. Advertising

  2. Torsten Mueller

    Bo Persson Guest

    Torsten Mueller wrote:
    > Where does it come from to make spaces everywhere but not between a
    > keyword and a condition?


    This is religious. Why are some people catholics or protestants?

    > I'm confronted with code looking like that:
    >
    > if( x == 3 && y == 7 && z == 1024 )
    > {
    > for( int i = 0; i < 1000 ; i++ )
    > {
    > }
    > }
    >
    > It's a company style guide convention. I would write it like this:
    >
    > if (x==3 && y==7 && z==1024)
    > {
    > for (int i=0; i<1000 ; i++)
    > {
    > }
    > }


    And I would write it

    if (x == 3 && y == 7 && z == 1024)
    {
    for (int i = 0; i != 1000; ++i)
    {
    }
    }

    because that is obviously so much better.

    Just see how good it looks! :)

    >
    > I find this much more readable.
    >
    > The style guide also forbids to make a space in method declarations
    > or definitions:
    >
    > class MyClass
    > {
    > void MyMethod(int param);
    > }; ^ no space!
    >
    > void MyClass::MyMethod(int param)
    > { ^ no space!
    > }
    >
    > Is there any serious reason for this?


    Yes, it would just look ugly.

    In my mind, the parameter list is an integral part of the function.
    For some reason, the condition of the if-statement is not.

    > Is this .NET or what??


    Don't think so.


    Bo Persson
    Bo Persson, Aug 7, 2008
    #2
    1. Advertising

  3. On 2008-08-07 12:58, Torsten Mueller wrote:
    > Where does it come from to make spaces everywhere but not between a
    > keyword and a condition? I'm confronted with code looking like that:
    >
    > if( x == 3 && y == 7 && z == 1024 )
    > {
    > for( int i = 0; i < 1000 ; i++ )
    > {
    > }
    > }
    >
    > It's a company style guide convention. I would write it like this:
    >
    > if (x==3 && y==7 && z==1024)
    > {
    > for (int i=0; i<1000 ; i++)
    > {
    > }
    > }
    >
    > I find this much more readable.
    >
    > The style guide also forbids to make a space in method declarations or
    > definitions:
    >
    > class MyClass
    > {
    > void MyMethod(int param);
    > }; ^ no space!
    >
    > void MyClass::MyMethod(int param)
    > { ^ no space!
    > }
    >
    > Is there any serious reason for this? Is this .NET or what??


    When it comes to style there are usually no objective reasons at all. My
    suspicion is that the space between keywords and expressions comes from
    languages which does not require parenthesis around the expression, like
    BASIC:

    IF $x = 0 THEN
    ...
    END

    --
    Erik Wikström
    Erik Wikström, Aug 7, 2008
    #3
  4. Erik Wikström <> wrote:

    > My suspicion is that the space between keywords and expressions
    > comes from languages which does not require parenthesis around the
    > expression, like BASIC:


    I think it's just because all other keywords (class, typedef, return,
    case) and also all integral types do require a space or a delimiter.
    These conditional keywords just do not because they require a
    condition in brackets. But I would treat them as keywords as well.

    T.M.
    Torsten Mueller, Aug 7, 2008
    #4
  5. "Bo Persson" <> wrote:

    > > Where does it come from to make spaces everywhere but not between
    > > a keyword and a condition?

    >
    > This is religious.


    Sure, but on both sides! And very emotional.

    T.M.
    Torsten Mueller, Aug 7, 2008
    #5
  6. Torsten Mueller <> writes:

    > Erik Wikström <> wrote:
    >
    >> My suspicion is that the space between keywords and expressions
    >> comes from languages which does not require parenthesis around the
    >> expression, like BASIC:

    >
    > I think it's just because all other keywords (class, typedef, return,
    > case) and also all integral types do require a space or a delimiter.


    Yes, that is a barely bearable inconsistency. Let's

    #define CLASS(C) class C
    #define TYPEDEF(T) typedef T
    // return allows () since you can always put () around an expression.
    #define CASE(C) case C


    > These conditional keywords just do not because they require a
    > condition in brackets. But I would treat them as keywords as well.



    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Aug 7, 2008
    #6
  7. Torsten Mueller

    Stefan Ram Guest

    Torsten Mueller <> writes:
    >Where does it come from to make spaces everywhere but not between a
    >keyword and a condition? I'm confronted with code looking like that:


    I can only legitimate my own personal style, which I give here:

    Indentation within Braces

    An indentation of just one space often is too small to be seen
    clearly, because the natural width and form of characters
    often varies by an amount that is not very much smaller than a
    space. Therefore, the indentation should amount to at least
    two positions. In order not to waste horizontal spaces, an
    indentation of exactly two positions is chosen. This means,
    that the left position of the next level is two larger than
    the position of the directly enclosing level.

    Indentation by two positions within a block

    { ++x;
    ++x; }
    ^ ^
    0 2

    Bad: A small indentation by one position is not always visible
    clearly

    {++x;
    ++x; }

    Good: The indentation by two positions is visible clearly

    { ++x;
    ++x; }

    Bad: A large indentation by more than two positions wastes
    horizontal space with no additional benefit

    { ++x;
    ++x; }

    Spaces within braces

    In mathematics, there are often no spaces at the inner side of
    parentheses or braces in expressions, but spaces are used
    indeed at the inner side of braces in set notation, when the
    braces contain a description (not when they contain a list).

    Spaces in set notation

    { x | x > 2 }

    This style is adopted here: One space is written at the inner
    side of braces.

    Spaces at the inner side of parentheses within a block

    { ++x; }

    This style is consistent with the indentation by two
    positions, because only using this style, corresponding parts
    of two lines have the same position.

    Bad: No space after the first brace, the two statements are
    misaligned

    {++x;
    ++x; }

    Good: One space after the first brace, the two statements are
    properly aligned

    { ++x;
    ++x; }

    Bad: Two spaces after the first brace, the two statements are
    misaligned

    { ++x;
    ++x; }

    There are some exceptions to this rule: No spaces are used
    within empty braces "{}" and between two or more closing
    braces of the same direction "}}", except, when the first one
    of them is part of an empty pair "{} }" (an empty pair of
    braces if treated like a single non-braces character).

    Unified rules for all Brackets

    For simplicity and uniformity, the rules from above apply to
    all kinds of brackets, including parentheses, braces (curly
    brackets), square brackets, and angle brackets.

    Spaces within parentheses and square brackets

    { y = f( x )+ g() + a[ 2 ]; }

    Binary operators are sorrounded by a space, but the space is
    omitted, when there already is a space on the other side of a
    sequence of brackets directly beside the operator: By this rule,
    " )+" is written instead of " ) +".

    Representation of the Syntactical Structure

    A method declaration in Java consists of a head and a body.
    The following representation shows this structure:

    Good formatting according to the structure

    void alpha() // head
    { beta(); } // body

    The following formatting is misleading, because the line break
    does not match the structural break:

    Bad line break within the body

    void alpha() { // head and the beginning of the body
    beta(); } // the rest of the body

    This formatting also would make no sense for blocks within
    blocks. So it is often not used for such blocks. Therefore
    even the adopters of this style can not use it uniformly.

    Opening Braces Look Like "bullets"

    There is a well known style to publish lists in typography
    using bullets sticking out on the left, looking like this:

    Common list representation with bullets in typography

    o This is the first point
    of this list, it is written
    here just as an example.

    o Here is another entry

    o This is another example given
    just as an example to show
    an example

    The braces of the beginnings of blocks stand out on the left
    just the same, when the formatting being described here is
    used, so they look quite naturally as beginning-of-a-block
    markers, when one is used to the typographical list notation:

    Left braces look like bullets to mark blocks

    { printf(); printf();
    printf(); printf(); printf();
    printf(); printf(); }

    { printf(); printf(); }

    { printf(); printf(); printf();
    printf(); printf();
    printf(); }

    Neutrality

    Someone wrote this C code:

    while( fgets( eingabe, sizeof eingabe, stdin ))
    if( sscanf( eingabe, "%d", &wert )!= 1 )
    fprintf( stderr, "Please enter a number!\n" );
    else
    summe += wert;

    It amazes me that I can add braces by my style conventions
    (not changing the meaning of the code)
    without the need to change the position of any character of
    the given code or need to change the overall number of lines:

    The code from above plus braces

    while( fgets( eingabe, sizeof eingabe, stdin ))
    { if( sscanf( eingabe, "%d", &wert )!= 1 )
    { fprintf( stderr, "Please enter a number!\n" ); }
    else
    { summe += wert; }}

    Insofar, my bracing style might be considered non-obtrusive.

    Lines per Contents

    Lines containing only a single brace waste vertical space, so
    less contents fits on the same screen space. Therefore, I usually
    avoid them, but sometimes I do use them, when this helps to
    increase readability. I also might temporarily use them when editing
    a section of code. Of course, they would help programmers paid or
    being judged by the lines-of-code productivity.
    Stefan Ram, Aug 7, 2008
    #7
  8. Torsten Mueller

    Stefan Ram Guest

    =?UTF-8?B?RXJpayBXaWtzdHLDtm0=?= <> writes:
    >When it comes to style there are usually no objective reasons at all. My
    >suspicion is that the space between keywords and expressions comes from
    >languages which does not require parenthesis around the expression, like
    >BASIC:
    >IF $x = 0 THEN
    >...
    >END


    The BASIC interpreter of the Pet 2001 stored an expression like
    »POS(0)« with 3 tokens: »POS(«, »0«, and »)«. So, when the user
    entered

    10PRINT POS (0)
    LIST

    , it would list this as

    10 PRINT POS(0)

    IIRC. This might have made the user believe, that there was
    something wrong with the space after »POS«, because the
    interpreter has adjusted his input by removing the space.
    Anyway, there was no use in typing it, when it was removed
    immediatly, so the user might have abandoned this habbit.
    Stefan Ram, Aug 7, 2008
    #8
  9. Torsten Mueller

    Guest

    On Aug 7, 5:58 am, Torsten Mueller <> wrote:
    > Where does it come from to make spaces everywhere but not between a
    > keyword and a condition? I'm confronted with code looking like that:
    >
    > if( x == 3 && y == 7 && z == 1024 )
    > {
    > for( int i = 0; i < 1000 ; i++ )
    > {
    > }
    > }
    >
    > It's a company style guide convention. I would write it like this:
    >
    > if (x==3 && y==7 && z==1024)
    > {
    > for (int i=0; i<1000 ; i++)
    > {
    > }
    > }
    >
    > I find this much more readable.
    >
    > The style guide also forbids to make a space in method declarations or
    > definitions:
    >
    > class MyClass
    > {
    > void MyMethod(int param);
    > }; ^ no space!
    >
    > void MyClass::MyMethod(int param)
    > { ^ no space!
    > }
    >
    > Is there any serious reason for this? Is this .NET or what??
    >
    > T.M.


    There's at least one reason to write code consistently, on a personal
    and organizational level. If you adhere to a style, your text
    searches become much simpler.
    , Aug 7, 2008
    #9
  10. Torsten Mueller

    Guest

    On Aug 8, 3:36 am, wrote:
    > There's at least one reason to write code consistently, on a personal
    > and organizational level. If you adhere to a style, your text
    > searches become much simpler.


    Fair point, but easily addressed by a few scripts.

    Live and let live I say. Let the "owner" of some code do it any way
    they want. If they're not delivering, and you think the coding style
    is part of the problem (e.g. people who's indentation is unrelated to
    their scopes tend to struggle making reliable systems), mention the
    issues and offer some practical tip. If they can't solve the problem
    (their way OR yours), get rid of them. If you take over ownership,
    change it any way you want.

    If you're the boss and you have a burning need to be draconian, ask
    for some code before the interview and don't accept anyone who's style
    differs from yours unless they agree to prostrate themselves before
    your spacing and kiss your parenthesis. You'll be doing them a
    favour, as they can tell you where to go before they tell their old
    boss. Have the decency not to badger the unsuspecting after they
    join.

    Really, the amount of corporate energy wasted on this over the years
    is staggering. I think it's because the important things, like
    getting the right "patterns" used at an architectural level, can't be
    done by a central committee scared of the real world. ;-P

    Cheers,
    Tony
    , Aug 8, 2008
    #10
  11. Torsten Mueller

    James Kanze Guest

    On Aug 7, 12:58 pm, Torsten Mueller <> wrote:
    > Where does it come from to make spaces everywhere but not
    > between a keyword and a condition?


    I don't know. The standard doesn't require it, and I've never
    seen it.

    > I'm confronted with code looking like that:


    > if( x == 3 && y == 7 && z == 1024 )
    > {
    > for( int i = 0; i < 1000 ; i++ )
    > {
    > }
    > }


    > It's a company style guide convention.


    Interesting.

    One common convention is to distiguish between the operator (...)
    and the punctuation (...) by using a space before the latter,
    but never before the former, e.g. "if ( someCondition )", but
    "someFunction( args )". (Whether there is a space after the (
    and before the ) tends to vary, depending on the convention.) I
    suspect that whoever wrote your companies guidelines was
    thinking of function calls when he said no space before a (, and
    didn't think to distinguish between function calls (where
    '(...)' is an operator) and punctuation.

    > I would write it like this:


    > if (x==3 && y==7 && z==1024)
    > {
    > for (int i=0; i<1000 ; i++)
    > {
    > }
    > }


    > I find this much more readable.


    How much white space, in general, is desirable, depends largely
    on taste and cultural conventions. In France, normal
    typographic conventions use considerably more white space than
    elsewhere, and programmers tend to prefer "spaced out" code; in
    Germany, normal typographic use very little space, and
    programmer tend to prefer something tighter. But of course,
    even within a given community, there is a lot of variance.

    > The style guide also forbids to make a space in method declarations or
    > definitions:


    > class MyClass
    > {
    > void MyMethod(int param);
    > }; ^ no space!


    > void MyClass::MyMethod(int param)
    > { ^ no space!
    > }


    > Is there any serious reason for this? Is this .NET or what??


    Well, apparently they are attempting to distinguish functions
    from other use of the parenthesis; although I tend to use the
    space before the ( for this, I do think that making the
    distinction is worthwhile.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 8, 2008
    #11
  12. Torsten Mueller

    Puppet_Sock Guest

    On Aug 7, 6:58 am, Torsten Mueller <> wrote:
    > Where does it come from

    [snip]
    > It's a company style guide convention.

    [snip]
    > The style guide also

    [snip]
    > Is there any serious reason for this? Is this .NET or what??


    It's a company style guide convention. That *is* a
    serious reason.

    Unless your company is the company that produced .NET,
    then it's not .NET. I've no idea why you would think
    it had anything to do with .NET.

    A company style guide isn't to get things perfect.
    It's to get all the developers making things the
    same way. Often there are no powerful reasons for
    doing things any particular way. But when you have
    more than a few developers, enough that somebody
    thought a company style guide is important enough
    to bother writing, then it is important that all
    the developers do things the same way.

    When you write some chunk of text and your cow-orker
    reviews it, you don't want him to be tripping over
    where you put the spaces. You want the review
    comments that come back to actually be addressing
    the quality of your code. Similarly when you
    review his code, you want to be able to spend
    your time untwisting his code and figuring out
    what is going on, not worrying about whether he
    has the "right" spaces in there.

    Or, six months or a year from now when you have
    to do maintenance work, you want to be able to
    spend your time worrying about what the code
    should do. You don't want a big religious war
    over how the code should look.

    Or, in the words of many parents, I don't want
    justice, I want peace and quiet. Getting bent
    over the exact details of code formatting is
    a waste of time. Besides, you can always get a
    code prettifier utility and make it pretty.
    Socks
    Puppet_Sock, Aug 8, 2008
    #12
    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:
    658
    Rob Nicholson
    May 28, 2005
  2. Replies:
    0
    Views:
    2,440
  3. Replies:
    1
    Views:
    779
    Bertilo Wennergren
    Nov 24, 2003
  4. Hardeep Rakhra
    Replies:
    8
    Views:
    629
    Hardeep Rakhra
    Jan 15, 2004
  5. Ken Varn
    Replies:
    0
    Views:
    424
    Ken Varn
    Apr 26, 2004
Loading...

Share This Page