Re: Left brace on a single line -- Question

Discussion in 'C++' started by James Kanze, Apr 6, 2008.

  1. James Kanze

    James Kanze Guest

    On 5 avr, 22:11, "Bryan Parkoff" <> wrote:
    > I want to know the best practice to write on both C / C++ source codes..
    > The best practice is to ensure readable. Should left brace be after
    > function or if on the same line or next line.


    In the case of a function or a class, I'd say that there are
    significant technical arguments for requiring 1) the opening
    left brace on a line by itself, in column one, and 2) in the
    case of functions, putting the return type on a line by itself,
    above the function. (The idea is that the name, qualified by
    the class if it is a member function, start in column 1.)

    > For example...


    > void Test( void) {
    > int a = 5;
    > printf( "%d\n", a);
    > }


    > or...


    > void Test( void)
    > {
    > int a = 5;
    > printf( "%d\n", a);
    > }


    > It applies to if. For example...


    > if (a == 5) {
    > printf( "%d\n", a);
    > printf( "End...\n";
    > }


    > or...


    > if (a == 5)
    > {
    > printf( "%d\n", a);
    > printf( "End...\n";
    > }


    In this case, it really doesn't matter. Choose one, and stick
    to it. (I would say that if the opening brace is on the same
    line, you should require it always. I'd also require it always
    in the other case, but it's less critical, since it is readily
    apparent if it is missing.)

    --
    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, Apr 6, 2008
    #1
    1. Advertising

  2. James Kanze

    stan Guest

    James Kanze wrote:
    > On 5 avr, 22:11, "Bryan Parkoff" <> wrote:
    >> I want to know the best practice to write on both C / C++ source codes.
    >> The best practice is to ensure readable. Should left brace be after
    >> function or if on the same line or next line.

    >
    > In the case of a function or a class, I'd say that there are
    > significant technical arguments for requiring 1) the opening
    > left brace on a line by itself, in column one, and 2) in the
    > case of functions, putting the return type on a line by itself,
    > above the function. (The idea is that the name, qualified by
    > the class if it is a member function, start in column 1.)


    While I prefer the above on a readibility/cosmetic pov, I don't think I've
    ever seen an actual technical argument other than it makes finding
    functions easier when searching by way of regular expressions. Is that
    the reason or are there other justifications?

    <bracing examples snipped>
     
    stan, Apr 7, 2008
    #2
    1. Advertising

  3. James Kanze

    James Kanze Guest

    On Apr 7, 2:33 am, stan <> wrote:
    > James Kanze wrote:
    > > On 5 avr, 22:11, "Bryan Parkoff" <> wrote:
    > >> I want to know the best practice to write on both C / C++ source codes.
    > >> The best practice is to ensure readable. Should left brace be after
    > >> function or if on the same line or next line.


    > > In the case of a function or a class, I'd say that there are
    > > significant technical arguments for requiring 1) the opening
    > > left brace on a line by itself, in column one, and 2) in the
    > > case of functions, putting the return type on a line by itself,
    > > above the function. (The idea is that the name, qualified by
    > > the class if it is a member function, start in column 1.)


    > While I prefer the above on a readibility/cosmetic pov, I
    > don't think I've ever seen an actual technical argument other
    > than it makes finding functions easier when searching by way
    > of regular expressions. Is that the reason or are there other
    > justifications?


    That's the reason. You can search for the definition, without
    getting any non-definition use. Also, vi uses a { in column one
    to recognize the start of a function body, and in practice,
    there'll be times that you'll have to edit with vi (or ed, which
    follows the same rules).

    --
    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, Apr 7, 2008
    #3
  4. James Kanze

    stan Guest

    James Kanze wrote:
    > On Apr 7, 2:33 am, stan <> wrote:
    >> James Kanze wrote:
    >> > On 5 avr, 22:11, "Bryan Parkoff" <> wrote:
    >> >> I want to know the best practice to write on both C / C++ source codes.
    >> >> The best practice is to ensure readable. Should left brace be after
    >> >> function or if on the same line or next line.

    >
    >> > In the case of a function or a class, I'd say that there are
    >> > significant technical arguments for requiring 1) the opening
    >> > left brace on a line by itself, in column one, and 2) in the
    >> > case of functions, putting the return type on a line by itself,
    >> > above the function. (The idea is that the name, qualified by
    >> > the class if it is a member function, start in column 1.)

    >
    >> While I prefer the above on a readibility/cosmetic pov, I
    >> don't think I've ever seen an actual technical argument other
    >> than it makes finding functions easier when searching by way
    >> of regular expressions. Is that the reason or are there other
    >> justifications?

    >
    > That's the reason. You can search for the definition, without
    > getting any non-definition use. Also, vi uses a { in column one
    > to recognize the start of a function body, and in practice,
    > there'll be times that you'll have to edit with vi (or ed, which
    > follows the same rules).


    While I've been there, writing code with ed seems a little too manly :)
    While I'm primarily an emacs type, I use vim enough to get by and help
    others sometimes but I'm not a vim guru. Thinking about it, I don't
    actually remember ever using an actual vi.

    I read that it's real hard/impossible to create a LALR or even yacc
    compatible grammer for c or c++. I've never sat down to try but my
    understanding is there are dark corners that cause problems. Is It
    possible to write a yacc grammer that simply recognizes function and
    class definitions? I know there are programs that detect functions but I
    believe they all do some clever pattern matching; I'm not aware of any
    that try actually parsing.
     
    stan, Apr 8, 2008
    #4
  5. James Kanze

    James Kanze Guest

    On Apr 8, 1:27 am, stan <> wrote:
    > James Kanze wrote:
    > > On Apr 7, 2:33 am, stan <> wrote:
    > >> James Kanze wrote:
    > >> > On 5 avr, 22:11, "Bryan Parkoff" <> wrote:
    > >> >> I want to know the best practice to write on both C /
    > >> >> C++ source codes. The best practice is to ensure
    > >> >> readable. Should left brace be after function or if on
    > >> >> the same line or next line.


    > >> > In the case of a function or a class, I'd say that there are
    > >> > significant technical arguments for requiring 1) the opening
    > >> > left brace on a line by itself, in column one, and 2) in the
    > >> > case of functions, putting the return type on a line by itself,
    > >> > above the function. (The idea is that the name, qualified by
    > >> > the class if it is a member function, start in column 1.)


    > >> While I prefer the above on a readibility/cosmetic pov, I
    > >> don't think I've ever seen an actual technical argument other
    > >> than it makes finding functions easier when searching by way
    > >> of regular expressions. Is that the reason or are there other
    > >> justifications?


    > > That's the reason. You can search for the definition, without
    > > getting any non-definition use. Also, vi uses a { in column one
    > > to recognize the start of a function body, and in practice,
    > > there'll be times that you'll have to edit with vi (or ed, which
    > > follows the same rules).


    > While I've been there, writing code with ed seems a little too manly :)


    You should have used the editor on the original Intel
    development systems, then. After that, ed seems like something
    for sissies. (The basic philosphy was something like ed, but it
    allowed multiple commands on the same line, with constructs for
    looping, etc. A typical command line looked a bit like
    transmission noise, and an error in a single character could
    wreck havoc in your file.)

    Seriously, I don't think I've used ed much except for very small
    editing jobs in a script.

    > While I'm primarily an emacs type, I use vim enough to get by
    > and help others sometimes but I'm not a vim guru. Thinking
    > about it, I don't actually remember ever using an actual vi.


    I still use it fairly often. Or production machines have a very
    limited environment, and we're not allowed to install just
    anything on them.

    > I read that it's real hard/impossible to create a LALR or even
    > yacc compatible grammer for c or c++.


    That's actually true for a lot of languages---even Pascal. The
    C/C++ declaration syntax, however, seems to be designed
    intentionally to make parsing difficult.

    > I've never sat down to try but my understanding is there are
    > dark corners that cause problems. Is It possible to write a
    > yacc grammer that simply recognizes function and class
    > definitions?


    If you're handling pre-processed input (or don't mind screwing
    up if someone was stupid enough to use the preprocessor in a way
    that messed with this), you can come pretty close with just
    regular expressions and a state machine. If you're interested,
    you might look at the code for my kloc program
    (http://kanze.james.neuf.fr/code-en.html, then look for kloc in
    the Exec directory). It collects a number of statistics (more
    or less accurately), such as the number of functions and the
    number of class definitions (those should be very accurate).
    It uses only lex and a very simple state machine; I won't say
    that it can't be fooled, but it does seem to work most of the
    time. (I think. It's really very old code, and I've not really
    verified it with templates. I did expand it to handle
    namespaces, but I wouldn't be surprised if it didn't get
    confused by template definitions which contain parentheses.)

    > I know there are programs that detect functions but I believe
    > they all do some clever pattern matching; I'm not aware of any
    > that try actually parsing.


    Any opening brace at namespace scope is either a class or a
    function definition. Knowing that you're at namespace scope

    The syntax for opening a namespace scope
    is pretty simple, so you should be able to track those
    (supposing no messing around with the preprocessor, of course)
    and `extern "C"' blocks. After that, any opening brace at
    namespace scope is the start of either a function, a class or an
    enum definition.

    --
    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, Apr 8, 2008
    #5
  6. James Kanze

    stan Guest

    James Kanze wrote:
    > On Apr 8, 1:27 am, stan <> wrote:
    >> James Kanze wrote:
    >> > On Apr 7, 2:33 am, stan <> wrote:
    >> >> James Kanze wrote:

    <snip>
    >> >> While I prefer the above on a readibility/cosmetic pov, I
    >> >> don't think I've ever seen an actual technical argument other
    >> >> than it makes finding functions easier when searching by way
    >> >> of regular expressions. Is that the reason or are there other
    >> >> justifications?

    >
    >> > That's the reason. You can search for the definition, without
    >> > getting any non-definition use. Also, vi uses a { in column one
    >> > to recognize the start of a function body, and in practice,
    >> > there'll be times that you'll have to edit with vi (or ed, which
    >> > follows the same rules).

    >
    >> While I've been there, writing code with ed seems a little too manly :)

    >
    > You should have used the editor on the original Intel
    > development systems, then. After that, ed seems like something
    > for sissies. (The basic philosphy was something like ed, but it
    > allowed multiple commands on the same line, with constructs for
    > looping, etc. A typical command line looked a bit like
    > transmission noise, and an error in a single character could
    > wreck havoc in your file.)


    I've used something that sounds very similar for some old embedded
    coumputers. Actually the word embedded never came up, they were just the
    command and control computers. Editing wasn't my biggest problem; they
    had an actual core memory and when a wire broke I had to take it down to
    a repair facility and solder the broken wire with a microscope. The only
    good thing was that the facility was just far enough away to make it a
    two day trip. I usually spent the first day repairing and the second day
    in the club :)
    >
    > Seriously, I don't think I've used ed much except for very small
    > editing jobs in a script.


    I really think if you had to write a very big program you would save
    time writing an editor first:)

    >> While I'm primarily an emacs type, I use vim enough to get by
    >> and help others sometimes but I'm not a vim guru. Thinking
    >> about it, I don't actually remember ever using an actual vi.

    >
    > I still use it fairly often. Or production machines have a very
    > limited environment, and we're not allowed to install just
    > anything on them.


    I never turn on compatibility. I might one day just to see if I can
    still get around without banging into things to badly. I've never found
    the vim help files terribly intuitive, what does the actual vi help look
    like? AFAIK there's no actual open vi, is that correct?

    >> I read that it's real hard/impossible to create a LALR or even
    >> yacc compatible grammer for c or c++.

    >
    > That's actually true for a lot of languages---even Pascal. The
    > C/C++ declaration syntax, however, seems to be designed
    > intentionally to make parsing difficult.


    I'm pretty comfortable with yacc/bison and flex and I've done many
    little language things so I have some feeling for working on front ends.
    However the urge to simply write a c or c++ front end never really
    bubbled up to the top of my todo list.

    >> I've never sat down to try but my understanding is there are
    >> dark corners that cause problems. Is It possible to write a
    >> yacc grammer that simply recognizes function and class
    >> definitions?

    >
    > If you're handling pre-processed input (or don't mind screwing
    > up if someone was stupid enough to use the preprocessor in a way
    > that messed with this), you can come pretty close with just
    > regular expressions and a state machine. If you're interested,
    > you might look at the code for my kloc program
    > (http://kanze.james.neuf.fr/code-en.html, then look for kloc in
    > the Exec directory). It collects a number of statistics (more
    > or less accurately), such as the number of functions and the
    > number of class definitions (those should be very accurate).
    > It uses only lex and a very simple state machine; I won't say
    > that it can't be fooled, but it does seem to work most of the
    > time. (I think. It's really very old code, and I've not really
    > verified it with templates. I did expand it to handle
    > namespaces, but I wouldn't be surprised if it didn't get
    > confused by template definitions which contain parentheses.)


    Thanks, I'll take a look. I've always found another solution every time
    I came upon the need but one of these days I really do need to sit down
    and take a look at this problem; if just for the learning. Last time I
    needed something I hacked together a script to read a tags file. Seems
    like the problem comes up often enough for me to add something a little
    better to my toolbox. Time always seems to work against me when the
    problem is actually staring at me.

    >> I know there are programs that detect functions but I believe
    >> they all do some clever pattern matching; I'm not aware of any
    >> that try actually parsing.

    >
    > Any opening brace at namespace scope is either a class or a
    > function definition. Knowing that you're at namespace scope
    >
    > The syntax for opening a namespace scope
    > is pretty simple, so you should be able to track those
    > (supposing no messing around with the preprocessor, of course)
    > and `extern "C"' blocks. After that, any opening brace at
    > namespace scope is the start of either a function, a class or an
    > enum definition.


    Sounds like a good start for my next rainy day project. Thanks.
     
    stan, Apr 10, 2008
    #6
  7. James Kanze

    James Kanze Guest

    On Apr 10, 5:19 am, stan <> wrote:
    > James Kanze wrote:


    [...]
    > > Seriously, I don't think I've used ed much except for very small
    > > editing jobs in a script.


    > I really think if you had to write a very big program you would save
    > time writing an editor first:)


    On the first Unix system I worked on, they had just finished
    modifying the OS and the compiler, in order to be able to handle
    programs as big as vi. Just to not have to use ed. The early
    Intel editor I used ran on an 8 bit machine with 64 KB, using a
    teletype as the console. In such an environment, it's hard to
    do better than ed.

    (FWIW: vi was the first full screen editor I ever used. Before
    that, they were all command line editors, like ed.)

    [...]
    > I've never found the vim help files terribly intuitive, what
    > does the actual vi help look like?


    What help? There is no on line help.

    > AFAIK there's no actual open vi, is that correct?


    I think there was, at one time. But why bother? If you're
    going to compile and install your own, you might as well make it
    vim (or emacs). (Our production machines are Sun Sparcs,
    running Solaris, and the only installed editors are those that
    are bundled with Solaris. Which means the pure Berkley vi, just
    as Bill Joy wrote it, when he was still a grad student, and
    hadn't helped found Sun.)

    > >> I read that it's real hard/impossible to create a LALR or even
    > >> yacc compatible grammer for c or c++.


    > > That's actually true for a lot of languages---even Pascal. The
    > > C/C++ declaration syntax, however, seems to be designed
    > > intentionally to make parsing difficult.


    > I'm pretty comfortable with yacc/bison and flex and I've done
    > many little language things so I have some feeling for working
    > on front ends. However the urge to simply write a c or c++
    > front end never really bubbled up to the top of my todo list.


    A C front end wouldn't be too difficult, despite the ambiguities
    in the declaration syntax. C++ probably requires backtracking.
    Still, I don't think it would be that difficult to get to the
    stage of building a parse tree. The real fun would start when
    you start to annotate it. Then comes name look up, function
    overload resolution, and templates.

    --
    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, Apr 10, 2008
    #7
  8. James Kanze

    stan Guest

    James Kanze wrote:
    > On Apr 10, 5:19 am, stan <> wrote:
    >> James Kanze wrote:

    >
    > [...]
    >> I've never found the vim help files terribly intuitive, what
    >> does the actual vi help look like?

    >
    > What help? There is no on line help.


    What was I thinking?
    >
    >> AFAIK there's no actual open vi, is that correct?

    >
    > I think there was, at one time. But why bother? If you're
    > going to compile and install your own, you might as well make it
    > vim (or emacs). (Our production machines are Sun Sparcs,
    > running Solaris, and the only installed editors are those that
    > are bundled with Solaris. Which means the pure Berkley vi, just
    > as Bill Joy wrote it, when he was still a grad student, and
    > hadn't helped found Sun.)


    I have vim. If available I might have loaded up vi to see how my hands
    reacted. Actually my hands are confused as I jump between vim and emacs.
    I might be risking permanent damage even trying a pure vi :)

    <snip>
    >> I'm pretty comfortable with yacc/bison and flex and I've done
    >> many little language things so I have some feeling for working
    >> on front ends. However the urge to simply write a c or c++
    >> front end never really bubbled up to the top of my todo list.

    >
    > A C front end wouldn't be too difficult, despite the ambiguities
    > in the declaration syntax. C++ probably requires backtracking.
    > Still, I don't think it would be that difficult to get to the
    > stage of building a parse tree. The real fun would start when
    > you start to annotate it. Then comes name look up, function
    > overload resolution, and templates.


    As I said, I think I might just give it a try.
     
    stan, Apr 11, 2008
    #8
    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. Derek Simmons
    Replies:
    1
    Views:
    554
    Derek Simmons
    Mar 31, 2005
  2. Andy Fish
    Replies:
    3
    Views:
    360
    Andy Fish
    Nov 19, 2003
  3. Kevin Simonson
    Replies:
    3
    Views:
    445
    Michael Borgwardt
    Nov 28, 2004
  4. Mac
    Replies:
    0
    Views:
    84
  5. Mac
    Replies:
    7
    Views:
    145
Loading...

Share This Page