Source Code Formatting Standard Update

Source Code Formatting Standard Update

[jyqvklioo]

I quote:
"
http://www.gnu.org/prep/standards/html_node/Formatting.html
5.1 Formatting Your Source Code
It is important to put the open-brace that starts the body of a 
C function in column one, so that they will start a defun.
"
Does emacs still have this limitation?
If not,
the standard can be updated to make the curly brace placement more consistent.


The next issue is not emacs specific, 
but here may be as good a place to address it as there is, as far as I can see.
"
In Standard C, if the arguments don't fit nicely on one line, split it like this:
     int
     lots_of_args (int an_integer, long a_long, short a_short,
                   double a_double, float a_float)
"
This practice produces poor results in languages with highly nested namespaces,
like object oriented languages. There you can get code like:

namespace.ClassName.NestedClass.nicelyDescriptiveClassName.staticMethod(namespace.ParameterObject
                                                                        a,
                                                                        otherNamespace.secondObject
                                                                        b);

If you line break at periods also, the names would span multiple lines.

Re: Source Code Formatting Standard Update

[Stefan Monnier]

> "
> http://www.gnu.org/prep/standards/html_node/Formatting.html
> 5.1 Formatting Your Source Code
> It is important to put the open-brace that starts the body of a 
> C function in column one, so that they will start a defun.
> "
> Does Emacs still have this limitation?
> If not, the standard can be updated to make the curly brace placement
> more consistent.

AFAIK, the standard was not designed like this because of Emacs's
limitations, but because it was considered a good habit.
I don't think this consideration has changed.

> "
> In Standard C, if the arguments don't fit nicely on one line, split it like this:
>      int
>      lots_of_args (int an_integer, long a_long, short a_short,
>                    double a_double, float a_float)
> "
> This practice produces poor results in languages with highly nested
> namespaces, like object oriented languages.  There you can get code
> like:

> namespace.ClassName.NestedClass.nicelyDescriptiveClassName.staticMethod(namespace.ParameterObject
>                                                                         a,
>                                                                         otherNamespace.secondObject
>                                                                         b);

Obviously, this is unreadable, so you should write it differently.
But if the alternatives are worse for one reason or another, the right
way to do it is to place a line break after the open-paren.


        Stefan

Source Code Formatting Standard Update

[jyqvklioo]

I quote:
"
http://www.gnu.org/prep/standards/html_node/Formatting.html
5.1 Formatting Your Source Code
It is important to put the open-brace that starts the body of a 
C function in column one, so that they will start a defun.
"
Does emacs still have this limitation?
If not,
the standard can be updated to make the curly brace placement more consistent.


The next issue is not emacs specific, 
but here may be as good a place to address it as there is, as far as I can see.
"
In Standard C, if the arguments don't fit nicely on one line, split it like this:
     int
     lots_of_args (int an_integer, long a_long, short a_short,
                   double a_double, float a_float)
"
This practice produces poor results in languages with highly nested namespaces,
like object oriented languages. There you can get code like:

namespace.ClassName.NestedClass.nicelyDescriptiveClassName.staticMethod(namespace.ParameterObject
                                                                        a,
                                                                        otherNamespace.secondObject
                                                                        b);

If you line break at periods also, the names would span multiple lines.

Source Code Formatting Standard Update

[jyqvklioo]

I quote:
"
http://www.gnu.org/prep/standards/html_node/Formatting.html
5.1 Formatting Your Source Code
It is important to put the open-brace that starts the body of a 
C function in column one, so that they will start a defun.
"
Does emacs still have this limitation?
If not,
the standard can be updated to make the curly brace placement more consistent.


The next issue is not emacs specific, 
but here may be as good a place to address it as there is, as far as I can see.
"
In Standard C, if the arguments don't fit nicely on one line, split it like this:
     int
     lots_of_args (int an_integer, long a_long, short a_short,
                   double a_double, float a_float)
"
This practice produces poor results in languages with highly nested namespaces,
like object oriented languages. There you can get code like:

namespace.ClassName.NestedClass.nicelyDescriptiveClassName.staticMethod(namespace.ParameterObject
                                                                        a,
                                                                        otherNamespace.secondObject
                                                                        b);

If you line break at periods also, the names would span multiple lines.

Re: Source Code Formatting Standard Update

[Alfred M. Szmidt]

Your mail client seems to be misconfigured, this is the third email
you send that is exactly the same.

Re: Source Code Formatting Standard Update

[David Kastrup]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Your mail client seems to be misconfigured, this is the third email
> you send that is exactly the same.

No, not exactly the same.  It is a basically unrecognizable way of
intermixing quote and replies.

You probably need to compare the mails with wdiff or something in order
to figure out what the author is trying to address in reply to what
points.

-- 
David Kastrup

Re: Source Code Formatting Standard Update

[Richard Stallman]

    AFAIK, the standard was not designed like this because of Emacs's
    limitations, but because it was considered a good habit.

I think it is a good style, but Emacs's convention about open-paren
in column zero was the crucial immediate reason.

Re: Source Code Formatting Standard Update

[jyqvklioo]

So, these days at least, there is no technical motivation for having the open curly brace '{' in column 0. I plea that the Standard be amended so that the { placement for the start of a body of a non-enclosed function is consistent with use otherwise. The increased consistency will also make it possible to have simpler implementations of automatic formatting software.

The other issue I addressed is also one that would simplify implementations of formatters and, in most software implemented in object oriented languages, improve readability.

I prefer to leave formatting source code to a machine; even more so when working in a team. When formatting is not available by automation, it sometimes does not get done. I would like to have a fast, standalone formatter as a pre commit hook to a VCS.

Re: Source Code Formatting Standard Update

[Alfred M. Szmidt]

   So, these days at least, there is no technical motivation for
   having the open curly brace '{' in column 0. I plea that the
   Standard be amended so that the { placement for the start of a body
   of a non-enclosed function is consistent with use otherwise. The
   increased consistency will also make it possible to have simpler
   implementations of automatic formatting software.

I'm not sure what you mean, the requirement is only for function
bodies, placing the curly at any other position seems very weird to
me.  And it makes it very simple to figure out what is a defun or
isn't, automatically and by the brain.

   I prefer to leave formatting source code to a machine; even more so
   when working in a team. When formatting is not available by
   automation, it sometimes does not get done. I would like to have a
   fast, standalone formatter as a pre commit hook to a VCS.

GNU indent does the right thing by default when it comes to the GNU
coding standards.  And you can supply switches so that it does the
right thing for your team.

Re: Source Code Formatting Standard Update

[jyqvklioo]

>> The increased consistency will also make it possible to have simpler
>> implementations of automatic formatting software.

>I'm not sure what you mean, 
>the requirement is only for function bodies, (...).

I mean to make the requirement for function bodies the same as for other blocks.  
To make example code with a loop:

void
functionName()
 {
   for(unsigned i=0;i<4;i++)
    {
      doMe(pretendItWrapped here,
         andCode continued);
    }
 }

Each parethesis, brace, or bracket can mean the same increase of indentation 
level.  Each { indicates a new block and sub-namespace.

For me this is more logical and understandable. I expect it is otherwise for 
some people.  Being accustomed to a certain practice is usual.

>GNU indent does the right thing by default when it comes to the GNU
>coding standards.

I tried 2 standalone programs previously.  1 of which was "GNU indent". 1 did 
not run on a non-unix platform, which at the time was a requirement, but may not 
be for other projects. The other was unreliable.

With the alterations I proposed, a hard coded formatter could be simple, speedy, 
and reliable: a combination I have not seen despite searching. Even if there 
were software available, there could be lighter weight, simpler software to 
implement the formatting if each parethesis, brace, or bracket resulted in the 
same increase of indentation level.

Re: Source Code Formatting Standard Update

[Alfred M. Szmidt]

   For me this is more logical and understandable. I expect it is
   otherwise for some people.  Being accustomed to a certain practice
   is usual.

That may be so, but curly at the 1st column is what is used in the GNU
project, and the GNU Coding Standard documents that practise.  If you
wish to use another style then you should ofcourse do so.  But that is
not a reason to modify our coding standards.

PS. GNU Indent works on non-unix platforms.

Re: Source Code Formatting Standard Update

[Stephen J. Turnbull]

jyqvklioo@googlemail.com writes:

 > I plea that the Standard be amended so that the { placement for the
 > start of a body of a non-enclosed function is consistent with use
 > otherwise.

-1

No thank you.  Good standards are good, bad standards are bad,
changing standards are the worst.  There is no strong reason to
change on the table, so let's not.

If you don't like the GNU standard, don't adopt it in your own
projects.  At the start of a new cooperative project, argue for what
you consider a more rational standard.  However, projects that have
followed it for a long time, including the whole GNU project, should
continue to do so unless a strong technical reason for changing can be
advanced.  A little bit of extra work for automatic formatters and
those who write them is not such a reason.

 > The increased consistency will also make it possible to have
 > simpler implementations of automatic formatting software.

What could be simpler than to just let Emacs do it?

Re: Source Code Formatting Standard Update

[Miles Bader]

jyqvklioo@googlemail.com writes:
> I mean to make the requirement for function bodies the same as for other blocks.  
> To make example code with a loop:
>
> void
> functionName()
>  {

Not going to happen.

-Miles

-- 
Innards, n. pl. The stomach, heart, soul, and other bowels.