[GRASS-dev] GRASS 7 development started

GRASS GRASS developer
1

Today the development of GRASS 6.4 has been moved out into
an own development branch. SVN trunk is now dedicated to GRASS 7
development which includes major refactoring of the code and
improvements to data formats etc.

What does that mean?

- Developers, users, who want to continue to develop GRASS 7:
  - do nothing, continue to use and work on SVN trunk

- Developers, users, who want to continue to develop GRASS 6.4:
  - Switch our local copy of GRASS-SVN from trunk to "develbranch_6":
           cd /path/to/your/local/copy/trunk
           svn switch https://svn.osgeo.org/grass/grass/branches/develbranch_6 .
    This switch will preserve local, uncommited changes.

Please help to make the relevant updated to Web/trac/Wiki pages.

Happy hacking,
Markus

2

Hi all,

related task --- development of wxPython should continue in
develbranch_6 (for 6.4 release). To avoid confusion I suggest to
remove gui/wxpython from trunk. Any objections?

Regards, Martin

2008/4/27 Markus Neteler <neteler@osgeo.org>:

Today the development of GRASS 6.4 has been moved out into
an own development branch. SVN trunk is now dedicated to GRASS 7
development which includes major refactoring of the code and
improvements to data formats etc.

What does that mean?

- Developers, users, who want to continue to develop GRASS 7:
  - do nothing, continue to use and work on SVN trunk

- Developers, users, who want to continue to develop GRASS 6.4:
  - Switch our local copy of GRASS-SVN from trunk to "develbranch_6":
           cd /path/to/your/local/copy/trunk
           svn switch https://svn.osgeo.org/grass/grass/branches/develbranch_6 .
    This switch will preserve local, uncommited changes.

Please help to make the relevant updated to Web/trac/Wiki pages.

Happy hacking,
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

3

Markus Neteler wrote:

Today the development of GRASS 6.4 has been moved out into
an own development branch. SVN trunk is now dedicated to GRASS 7
development which includes major refactoring of the code and
improvements to data formats etc.

Can we finalise the coding style, so that we can apply it?

This should be done before we start making substantial changes. Once
the code has been re-formatted, it will become much harder to compare
"before" and "after" versions, as any such diff will be dominated by
the formatting changes.

My personal preference is:

indent -bad -bap -bbb -bl -bli0 -bls -cli0 -cs -fc1 -hnl -i4 -l79 \
       -nbbo -nbc -nbfda -nbfde -ncdb -ncdw -nce -nfca -npcs -nprs \
       -npsl -nsc -nsob -saf -sai -saw -sbi0 -ss -ts8 -ut

Descriptions of the above options are given below, although it may be
more clear to just apply the above command to a bunch of files and
look at them.

Others will presumably have different preferences; in which case
please express them sooner rather than later.

The precise style doesn't really matter[1]; what DOES matter is that
we have one style for all of GRASS, and that everyone abides by it[2].

[1] Except for -ts8, which isn't a stylistic choice but a file format
issue. Using something other than -ts8 is irrational; the only other
sane alternative is to just forbid tabs outright (-nut, --no-tabs).

This is particularly important for Python code, where indentation is
syntatic, not just stylistic. I would suggest using "python -t -t ..."
to catch this.

[2] The main advantage of 7.x is the ability to make incompatible API
changes. Any such changes will typically require changing files across
large numbers of modules. Expecting developers to modify their text
editor's formatting settings from one file to the next (because
different files have different formatting) is unacceptable, IMHO.

Descriptions of the above options:

       -bad, --blank-lines-after-declarations
           Force blank lines after the declarations.

       -bap, --blank-lines-after-procedures
           Force blank lines after procedure bodies.

       -bbb, --blank-lines-before-block-comments
           Force blank lines before block comments.

       -bl, --braces-after-if-line
           Put braces on line after if, etc.

       -blin, --brace-indentn
           Indent braces n spaces.

       -bls, --braces-after-struct-decl-line
           Put braces on the line after struct declaration lines.

       -clin, --case-indentationn
           Case label indent of n spaces.

       -cs, --space-after-cast
           Put a space after a cast operator.

       -fc1, --format-first-column-comments
           Format comments in the first column.

       -hnl, --honour-newlines
           Prefer to break long lines at the position of newlines in the
           input.

       -in, --indent-leveln
           Set indentation level to n spaces.

       -ln, --line-lengthn
           Set maximum line length for non-comment lines to n.

       -nbbo, --break-after-boolean-operator
           Do not prefer to break long lines before boolean operators.

       -nbc, --no-blank-lines-after-commas
           Do not force newlines after commas in declarations.

       -nbfda, --dont-break-function-decl-args
           Don't put each argument in a function declaration on a seperate
           line.

       -nbfde, --dont-break-function-decl-args
           Break the line after the last argument in a declaration.

       -ncdb, --no-comment-delimiters-on-blank-lines
           Do not put comment delimiters on blank lines.

       -ncdw, --dont-cuddle-do-while
           Do not cuddle } and the while of a do {} while;.

       -nce, --dont-cuddle-else
           Do not cuddle } and else.

       -nfca, --dont-format-comments
           Do not format any comments.

       -npcs, --no-space-after-function-call-names
           Do not put space after the function in function calls.

       -nprs, --no-space-after-parentheses
           Do not put a space after every '(' and before every ')'.

       -npsl, --dont-break-procedure-type
           Put the type of a procedure on the same line as its name.

       -nsc, --dont-star-comments
           Do not put the `*' character at the left of comments.

       -nsob, --leave-optional-blank-lines
           Do not swallow optional blank lines.

       -saf, --space-after-for
           Put a space after each for.

       -sai, --space-after-if
           Put a space after each if.

       -saw, --space-after-while
           Put a space after each while.

       -sbin, --struct-brace-indentationn
           Indent braces of a struct, union or enum N spaces.

       -ss, --space-special-semicolon
           On one-line for and while statments, force a blank before the semi-
           colon.

       -tsn, --tab-sizen
           Set tab size to n spaces.

       -ut, --use-tabs
           Use tabs. This is the default.

--
Glynn Clements <glynn@gclements.plus.com>

4

On Mon, Apr 28, 2008 at 3:59 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

> Today the development of GRASS 6.4 has been moved out into
> an own development branch. SVN trunk is now dedicated to GRASS 7
> development which includes major refactoring of the code and
> improvements to data formats etc.

Can we finalise the coding style, so that we can apply it?

This should be done before we start making substantial changes. Once
the code has been re-formatted, it will become much harder to compare
"before" and "after" versions, as any such diff will be dominated by
the formatting changes.

I fully agree. I lack experience with "indent", so I just trust your
suggestions.
Glynn, can you apply it if there are no objections?

Markus

5

2008/4/28 Markus Neteler <neteler@osgeo.org>:

> This should be done before we start making substantial changes. Once
> the code has been re-formatted, it will become much harder to compare
> "before" and "after" versions, as any such diff will be dominated by
> the formatting changes.

I fully agree. I lack experience with "indent", so I just trust your
suggestions.
Glynn, can you apply it if there are no objections?

+1

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

6

Glynn wrote:

Can we finalise the coding style, so that we can apply it?

This should be done before we start making substantial changes. Once
the code has been re-formatted, it will become much harder to compare
"before" and "after" versions, as any such diff will be dominated by
the formatting changes.

My personal preference is:

indent -bad -bap -bbb -bl -bli0 -bls -cli0 -cs -fc1 -hnl -i4 -l79 \
       -nbbo -nbc -nbfda -nbfde -ncdb -ncdw -nce -nfca -npcs -nprs \
       -npsl -nsc -nsob -saf -sai -saw -sbi0 -ss -ts8 -ut

Descriptions of the above options are given below, although it may be
more clear to just apply the above command to a bunch of files and
look at them.

Others will presumably have different preferences; in which case
please express them sooner rather than later.

The precise style doesn't really matter[1]; what DOES matter is that
we have one style for all of GRASS, and that everyone abides by it[2].

[1] Except for -ts8, which isn't a stylistic choice but a file format
issue. Using something other than -ts8 is irrational; the only other
sane alternative is to just forbid tabs outright (-nut, --no-tabs).

This is particularly important for Python code, where indentation is
syntatic, not just stylistic. I would suggest using "python -t -t ..."
to catch this.

[2] The main advantage of 7.x is the ability to make incompatible API
changes. Any such changes will typically require changing files across
large numbers of modules. Expecting developers to modify their text
editor's formatting settings from one file to the next (because
different files have different formatting) is unacceptable, IMHO.

Descriptions of the above options:

       -bad, --blank-lines-after-declarations
           Force blank lines after the declarations.

       -bap, --blank-lines-after-procedures
           Force blank lines after procedure bodies.

       -bbb, --blank-lines-before-block-comments
           Force blank lines before block comments.

       -bl, --braces-after-if-line
           Put braces on line after if, etc.

       -blin, --brace-indentn
           Indent braces n spaces.

       -bls, --braces-after-struct-decl-line
           Put braces on the line after struct declaration lines.

       -clin, --case-indentationn
           Case label indent of n spaces.

       -cs, --space-after-cast
           Put a space after a cast operator.

       -fc1, --format-first-column-comments
           Format comments in the first column.

       -hnl, --honour-newlines
           Prefer to break long lines at the position of newlines
in the
           input.

       -in, --indent-leveln
           Set indentation level to n spaces.

       -ln, --line-lengthn
           Set maximum line length for non-comment lines to n.

       -nbbo, --break-after-boolean-operator
           Do not prefer to break long lines before boolean operators.

       -nbc, --no-blank-lines-after-commas
           Do not force newlines after commas in declarations.

       -nbfda, --dont-break-function-decl-args
           Don't put each argument in a function declaration on a
seperate
           line.

       -nbfde, --dont-break-function-decl-args
           Break the line after the last argument in a declaration.

       -ncdb, --no-comment-delimiters-on-blank-lines
           Do not put comment delimiters on blank lines.

       -ncdw, --dont-cuddle-do-while
           Do not cuddle } and the while of a do {} while;.

       -nce, --dont-cuddle-else
           Do not cuddle } and else.

       -nfca, --dont-format-comments
           Do not format any comments.

       -npcs, --no-space-after-function-call-names
           Do not put space after the function in function calls.

       -nprs, --no-space-after-parentheses
           Do not put a space after every '(' and before every ')'.

       -npsl, --dont-break-procedure-type
           Put the type of a procedure on the same line as its name.

       -nsc, --dont-star-comments
           Do not put the `*' character at the left of comments.

       -nsob, --leave-optional-blank-lines
           Do not swallow optional blank lines.

       -saf, --space-after-for
           Put a space after each for.

       -sai, --space-after-if
           Put a space after each if.

       -saw, --space-after-while
           Put a space after each while.

       -sbin, --struct-brace-indentationn
           Indent braces of a struct, union or enum N spaces.

       -ss, --space-special-semicolon
           On one-line for and while statments, force a blank before
the semi-
           colon.

       -tsn, --tab-sizen
           Set tab size to n spaces.

       -ut, --use-tabs
           Use tabs. This is the default.

FWIW this is how those rules differ from what is currently given in the
SUBMITTING file and what is at
http://grass.osgeo.org/wiki/Development#Explanation_of_C_indentation_rules

--- submitting 2008-04-29 09:45:35.000000000 +1200
+++ glynn 2008-04-29 09:45:47.000000000 +1200
@@ -1,33 +1,32 @@
+ -bad
  -bap
  -bbb
- -bli1
+ -bl
+ -bli0
  -bls
- -br
- -cbi0
- -ci4
  -cli0
- -d0
- -di0
+ -cs
  -fc1
  -hnl
  -i4
- -ip4
- -l80
- -lc80
- -lp
- -nbad
+ -l79
  -nbbo
  -nbc
+ -nbfda
+ -nbfde
  -ncdb
+ -ncdw
  -nce
- -ncs
  -nfca
  -npcs
  -nprs
  -npsl
+ -nsc
  -nsob
- -pi4
+ -saf
+ -sai
+ -saw
  -sbi0
- -sc
  -ss
  -ts8
+ -ut

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

7

Glynn Clements <glynn@gclements.plus.com> writes:

[...]

> My personal preference is:

> indent -bad -bap -bbb -bl -bli0 -bls -cli0 -cs -fc1 -hnl -i4 -l79 \
> -nbbo -nbc -nbfda -nbfde -ncdb -ncdw -nce -nfca -npcs -nprs \
> -npsl -nsc -nsob -saf -sai -saw -sbi0 -ss -ts8 -ut

> Descriptions of the above options are given below, although it may be
> more clear to just apply the above command to a bunch of files and
> look at them.

> Others will presumably have different preferences; in which case
> please express them sooner rather than later.

[...]

> -bl, --braces-after-if-line Put braces on line after if, etc.

  While I don't care much about the other options, I dislike this
  particular choice as error-prone. It's much easier to move or
  copy the { } block without the `if' statement (and get a still
  syntactically-valid code) in this case:

if (...)
{
  ...
}

  than it's in this:

if (...) {
  ...
}

  The same applies to:

do
{
  ...
}
while (...);

  vs.:

do {
  ...
} while (...);

  And, to a lesser extent, to `struct', `union' and `enum'
  definitions.

  (This, however, doesn't apply to the function bodies.)

[...]

8

On Mon, 28 Apr 2008, Glynn Clements wrote:

Markus Neteler wrote:

Today the development of GRASS 6.4 has been moved out into
an own development branch. SVN trunk is now dedicated to GRASS 7
development which includes major refactoring of the code and
improvements to data formats etc.

Can we finalise the coding style, so that we can apply it?

This should be done before we start making substantial changes. Once
the code has been re-formatted, it will become much harder to compare
"before" and "after" versions, as any such diff will be dominated by
the formatting changes.

My personal preference is:

indent -bad -bap -bbb -bl -bli0 -bls -cli0 -cs -fc1 -hnl -i4 -l79 \
      -nbbo -nbc -nbfda -nbfde -ncdb -ncdw -nce -nfca -npcs -nprs \
      -npsl -nsc -nsob -saf -sai -saw -sbi0 -ss -ts8 -ut

Descriptions of the above options are given below, although it may be
more clear to just apply the above command to a bunch of files and
look at them.

I did that, and was pleasantly surprised to see that some C source files I had written hadn't changed much at all. Have just a couple of comments/queries that I will mention below.

Others will presumably have different preferences; in which case
please express them sooner rather than later.

The precise style doesn't really matter[1]; what DOES matter is that
we have one style for all of GRASS, and that everyone abides by it[2].

[1] Except for -ts8, which isn't a stylistic choice but a file format
issue. Using something other than -ts8 is irrational; the only other
sane alternative is to just forbid tabs outright (-nut, --no-tabs).

Allowing no tabs at all wouldn't be all that bad IMHO either. FFmpeg does it and it makes it very simple to see if patches submitted there comply with the whitespace formatting conventions - if there are any tabs at all, it's rejected. My main query is whether code that contains mixed tabs and spaces is "illegal" - I suspect it should be - and if all occurences of 8 consecutive space characters are required to be converted to a tab?

I find sometimes after a lot of editing of a piece of code and adjusting the indenting, that the occurence of spaces and tabs becomes quite mixed (generally as a result of me not knowing how to set indentation settings in my editor). In this case I think not allowing tabs and just spaces makes it easier to fix things up again manually.

This is particularly important for Python code, where indentation is
syntatic, not just stylistic. I would suggest using "python -t -t ..."
to catch this.

[2] The main advantage of 7.x is the ability to make incompatible API
changes. Any such changes will typically require changing files across
large numbers of modules. Expecting developers to modify their text
editor's formatting settings from one file to the next (because
different files have different formatting) is unacceptable, IMHO.

Descriptions of the above options:

[...]

      -cs, --space-after-cast
          Put a space after a cast operator.

When looking at the reformatted code this one jumped out at me as not being the usual way I would write it. I think in my head the idea is a cast normally does not actually modify the meaning of data the way another operator might, and thus putting it right up against the value being cast (without a space) somehow conveys that better. That's all.

Another strange thing I noticed in the reformatted code (I'm not sure which option causes it), is that the following code snippet
---------------------
                 if (totalfonts >= maxfonts)
                 {
                     maxfonts += 20;
                     fontcap = (struct GFONT_CAP *) G_realloc(fontcap,
                                          maxfonts * sizeof(struct GFONT_CAP));
                 }
---------------------
became this:
---------------------
                 if (totalfonts >= maxfonts)
                 {
                     maxfonts += 20;
                     fontcap = (struct GFONT_CAP *) G_realloc(fontcap,
                                                              maxfonts *
                                                              sizeof(struct
                                                                     GFONT_CAP));
                 }
---------------------

In the original example, when writing the code, I had moved the start of the continuation line back to avoid something ugly happening like in the indented code. I think the original version is easier to read though.

And that's about it for my preferences.

Paul

9

Paul Kelly <paul-grass@stjohnspoint.co.uk> writes:

>>> Today the development of GRASS 6.4 has been moved out into an own
>>> development branch. SVN trunk is now dedicated to GRASS 7
>>> development which includes major refactoring of the code and
>>> improvements to data formats etc.

>> Can we finalise the coding style, so that we can apply it?

>> This should be done before we start making substantial changes. Once
>> the code has been re-formatted, it will become much harder to
>> compare "before" and "after" versions, as any such diff will be
>> dominated by the formatting changes.

>> My personal preference is:

>> indent -bad -bap -bbb -bl -bli0 -bls -cli0 -cs -fc1 -hnl -i4 -l79 \
>> -nbbo -nbc -nbfda -nbfde -ncdb -ncdw -nce -nfca -npcs -nprs \
>> -npsl -nsc -nsob -saf -sai -saw -sbi0 -ss -ts8 -ut

[...]

>> Others will presumably have different preferences; in which case
>> please express them sooner rather than later.

>> The precise style doesn't really matter[1]; what DOES matter is that
>> we have one style for all of GRASS, and that everyone abides by
>> it[2].

>> [1] Except for -ts8, which isn't a stylistic choice but a file
>> format issue. Using something other than -ts8 is irrational; the
>> only other sane alternative is to just forbid tabs outright (-nut,
>> --no-tabs).

> Allowing no tabs at all wouldn't be all that bad IMHO either. FFmpeg
> does it and it makes it very simple to see if patches submitted there
> comply with the whitespace formatting conventions - if there are any
> tabs at all, it's rejected. My main query is whether code that
> contains mixed tabs and spaces is "illegal" - I suspect it should be
> - and if all occurences of 8 consecutive space characters are
> required to be converted to a tab?

> I find sometimes after a lot of editing of a piece of code and
> adjusting the indenting, that the occurence of spaces and tabs
> becomes quite mixed (generally as a result of me not knowing how to
> set indentation settings in my editor). In this case I think not
> allowing tabs and just spaces makes it easier to fix things up again
> manually.

  There's no need to fix TABs manually, as there're already the
  `expand' and `unexpand' tools.

http://www.gnu.org/software/coreutils/manual/html_node/expand-invocation.html
http://www.gnu.org/software/coreutils/manual/html_node/unexpand-invocation.html

[...]

>> -cs, --space-after-cast Put a space after a cast operator.

> When looking at the reformatted code this one jumped out at me as not
> being the usual way I would write it. I think in my head the idea is
> a cast normally does not actually modify the meaning of data the way
> another operator might, and thus putting it right up against the
> value being cast (without a space) somehow conveys that
> better. That's all.

  Speaking of personal preferences, I'd prefer no space after a
  cast, too.

> Another strange thing I noticed in the reformatted code (I'm not sure
> which option causes it), is that the following code snippet

> ---------------------
> if (totalfonts >= maxfonts)
> {
> maxfonts += 20;
> fontcap = (struct GFONT_CAP *) G_realloc(fontcap,
> maxfonts * sizeof(struct GFONT_CAP));
> }
> ---------------------
> became this:
> ---------------------
> if (totalfonts >= maxfonts)
> {
> maxfonts += 20;
> fontcap = (struct GFONT_CAP *) G_realloc(fontcap,
> maxfonts *
> sizeof(struct
> GFONT_CAP));
> }
> ---------------------

> In the original example, when writing the code, I had moved the start
> of the continuation line back to avoid something ugly happening like
> in the indented code. I think the original version is easier to read
> though.

  I think that it doesn't look too good either way. You may
  consider introducing a temporary variable at the beginning of
  the block, e. g.:

   {
       void *new
           = G_realloc (fontcap,
                        ((maxfonts += 20, maxfonts)
                         * sizeof (*fontcap)));
       fontcap = (struct GFONT_CAP *)new;
   }

  At least as of GCC, `sizeof' allows either type name or an
  instance as an argument, and I feel that this feature is
  available at least as of ISO C89. If it's indeed so, I think
  it's advisable to use it in most of the new code, as it makes
  the code somewhat easier to read.

  Alternatively, a helper macro could be used, e. g.:

#define REALLOC_ARY(x, y) \
    (realloc ((x), (y) * sizeof (*(x))))

/* ... */

   {
       maxfonts += 20;
       fontcap = (struct GFONT_CAP *)REALLOC_ARY (fontcap, maxfonts);
   }

  or:

#define REALLOC_ARY(x, y, cast) \
    ((x) = (cast)realloc ((x), (y) * sizeof (*(x))))

/* ... */

   {
       maxfonts += 20;
       REALLOC_ARY (fontcap, maxfonts, struct GFONT_CAP *);
   }

  GNU C allows for an even better variant:

#define REALLOC_ARY(x, y) \
    (((x) = (typeof ((x)))realloc ((x), (y) * sizeof (*(x)))))

/* ... */

   {
       maxfonts += 20;
       REALLOC_ARY (fontcap, maxfonts);
   }

  But it's apparently non-portable.

> And that's about it for my preferences.

10

Paul Kelly wrote:

> Others will presumably have different preferences; in which case
> please express them sooner rather than later.
>
> The precise style doesn't really matter[1]; what DOES matter is that
> we have one style for all of GRASS, and that everyone abides by it[2].
>
> [1] Except for -ts8, which isn't a stylistic choice but a file format
> issue. Using something other than -ts8 is irrational; the only other
> sane alternative is to just forbid tabs outright (-nut, --no-tabs).

Allowing no tabs at all wouldn't be all that bad IMHO either. FFmpeg does
it and it makes it very simple to see if patches submitted there comply
with the whitespace formatting conventions - if there are any tabs at all,
it's rejected. My main query is whether code that contains mixed tabs and
spaces is "illegal" - I suspect it should be - and if all occurences of 8
consecutive space characters are required to be converted to a tab?

Personally, I don't have a problem with mixing spaces and tabs.

But then I take the view that tab stops being every 8 columns is
essentially a law of nature. Some text editors may allow you to
*pretend* otherwise, but that doesn't actually change reality.

Mixing tabs and spaces only becomes an issue once the people who think
that their editor's settings mean anything start expecting other
people to share their delusion. Once the meaning of a tab character
ceases to be unambiguous, the only remaining option is to simply
abandon tabs altogether.

I find sometimes after a lot of editing of a piece of code and adjusting
the indenting, that the occurence of spaces and tabs becomes quite mixed
(generally as a result of me not knowing how to set indentation settings
in my editor).

FWIW, in (X)Emacs, it's controlled by indent-tabs-mode. If nil,
indentation only uses spaces; if non-nil, indenting by N columns uses
N/8 tabs followed by N%8 spaces.

> -cs, --space-after-cast
> Put a space after a cast operator.

When looking at the reformatted code this one jumped out at me as not
being the usual way I would write it. I think in my head the idea is a
cast normally does not actually modify the meaning of data the way another
operator might, and thus putting it right up against the value being cast
(without a space) somehow conveys that better. That's all.

Hmm; I can see the point. I wouldn't put a space in *x or ++x, so I'm
not sure why I put it in "(type) x".

But then, even after all 20+ years of C programming, I still have
trouble deciding whether I prefer spaces around infix operators.

Another strange thing I noticed in the reformatted code (I'm not sure
which option causes it), is that the following code snippet
---------------------
                 if (totalfonts >= maxfonts)
                 {
                     maxfonts += 20;
                     fontcap = (struct GFONT_CAP *) G_realloc(fontcap,
                                          maxfonts * sizeof(struct GFONT_CAP));
                 }
---------------------
became this:
---------------------
                 if (totalfonts >= maxfonts)
                 {
                     maxfonts += 20;
                     fontcap = (struct GFONT_CAP *) G_realloc(fontcap,
                                                              maxfonts *
                                                              sizeof(struct
                                                                     GFONT_CAP));
                 }
---------------------

In the original example, when writing the code, I had moved the start of
the continuation line back to avoid something ugly happening like in the
indented code. I think the original version is easier to read though.

In that situation, I tend to break immediately after the opening
bracket, i.e.:

  fontcap = (struct GFONT_CAP *) G_realloc(
    fontcap, maxfonts * sizeof(struct GFONT_CAP));

The main reason is that, otherwise, XEmacs does what indent does, i.e.
indent all arguments to match the first argument.

Unfortunately, indent just eats the newline, even with -hnl.

In this particular case, you can sidestep the issue by omitting the
explicit cast of the return value.

--
Glynn Clements <glynn@gclements.plus.com>

11

Markus Neteler wrote:

> > Today the development of GRASS 6.4 has been moved out into
> > an own development branch. SVN trunk is now dedicated to GRASS 7
> > development which includes major refactoring of the code and
> > improvements to data formats etc.
>
> Can we finalise the coding style, so that we can apply it?
>
> This should be done before we start making substantial changes. Once
> the code has been re-formatted, it will become much harder to compare
> "before" and "after" versions, as any such diff will be dominated by
> the formatting changes.

I fully agree. I lack experience with "indent", so I just trust your
suggestions.
Glynn, can you apply it if there are no objections?

I think that we should allow a couple of days for feedback. In
particular, if there are any options which make life difficult for
users of specific text editors (or other tools), we should probably
change that.

Once the final style is decided, it would be better for the change to
be committed by someone with reasonable upload bandwidth, given that
it's likely to affect the majority of C source files.

Running indent on the entire source tree amounts to:

  find . -type f -name '*.c' | xargs indent <options>

--
Glynn Clements <glynn@gclements.plus.com>

12

On 29.04.2008 19:48, Glynn Clements wrote:

Once the final style is decided, it would be better for the change to
be committed by someone with reasonable upload bandwidth, given that
it's likely to affect the majority of C source files.

Running indent on the entire source tree amounts to:

  find . -type f -name '*.c' | xargs indent <options>

find also has the nice -exec switch, which will allow you to have find exec indent. It's probably a bit faster.

find . -type f -name '*.c' -exec indent <options> {} \;

I can do that, I have a 10 Mb connection.

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

13

"WB" == Wolf Bergenheim <wolf+grass@bergenheim.net> writes:

>> Once the final style is decided, it would be better for the change
>> to be committed by someone with reasonable upload bandwidth, given
>> that it's likely to affect the majority of C source files.

>> Running indent on the entire source tree amounts to:

>> find . -type f -name '*.c' | xargs indent <options>

> find also has the nice -exec switch, which will allow you to have
> find exec indent. It's probably a bit faster.

> find . -type f -name '*.c' -exec indent <options> {} \;

  Actually, it'd most probably be a bit /slower/, as `find' will
  fork () & exec () `indent' for each file it finds, while `xargs'
  will only fork () & exec () for each N files (where N depends on
  a system, but typically > 10.)

> I can do that, I have a 10 Mb connection.

  No objection on that, once the style is decided.

14

Glynn wrote:

Can we finalise the coding style, so that we can apply it?

I'd like to comment on this, but I'm quite busy right now so please give
me a little more time to get back before committing anything.

In general- I'm pretty relaxed about it and if you want to see my
preferences have a look at what's already there in the SUBMITTING file.
:wink:

I'll try to get back in the next day or two with a diff by diff comment.

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

15

Glynn wrote:
> Can we finalise the coding style, so that we can apply it?
>
> This should be done before we start making substantial changes. Once
> the code has been re-formatted, it will become much harder to compare
> "before" and "after" versions, as any such diff will be dominated by
> the formatting changes.
>
> My personal preference is:
>
> indent -bad -bap -bbb -bl -bli0 -bls -cli0 -cs -fc1 -hnl -i4 -l79 \
> -nbbo -nbc -nbfda -nbfde -ncdb -ncdw -nce -nfca -npcs -nprs \
> -npsl -nsc -nsob -saf -sai -saw -sbi0 -ss -ts8 -ut
>
> Descriptions of the above options are given below, although it may be
> more clear to just apply the above command to a bunch of files and
> look at them.
>
> Others will presumably have different preferences; in which case
> please express them sooner rather than later.
>
> The precise style doesn't really matter[1]; what DOES matter is that
> we have one style for all of GRASS, and that everyone abides by
it[2].
>
> [1] Except for -ts8, which isn't a stylistic choice but a file format
> issue. Using something other than -ts8 is irrational; the only other
> sane alternative is to just forbid tabs outright (-nut, --no-tabs).
>
> This is particularly important for Python code, where indentation is
> syntatic, not just stylistic. I would suggest using "python -t -t
..."
> to catch this.
>
> [2] The main advantage of 7.x is the ability to make incompatible API
> changes. Any such changes will typically require changing files
across
> large numbers of modules. Expecting developers to modify their text
> editor's formatting settings from one file to the next (because
> different files have different formatting) is unacceptable, IMHO.
>
> Descriptions of the above options:
>
> -bad, --blank-lines-after-declarations
> Force blank lines after the declarations.
>
> -bap, --blank-lines-after-procedures
> Force blank lines after procedure bodies.
>
> -bbb, --blank-lines-before-block-comments
> Force blank lines before block comments.
>
> -bl, --braces-after-if-line
> Put braces on line after if, etc.
>
> -blin, --brace-indentn
> Indent braces n spaces.
>
> -bls, --braces-after-struct-decl-line
> Put braces on the line after struct declaration lines.
>
> -clin, --case-indentationn
> Case label indent of n spaces.
>
> -cs, --space-after-cast
> Put a space after a cast operator.
>
> -fc1, --format-first-column-comments
> Format comments in the first column.
>
> -hnl, --honour-newlines
> Prefer to break long lines at the position of
newlines
> in the
> input.
>
> -in, --indent-leveln
> Set indentation level to n spaces.
>
> -ln, --line-lengthn
> Set maximum line length for non-comment lines to n.
>
> -nbbo, --break-after-boolean-operator
> Do not prefer to break long lines before boolean
operators.
>
> -nbc, --no-blank-lines-after-commas
> Do not force newlines after commas in declarations.
>
> -nbfda, --dont-break-function-decl-args
> Don't put each argument in a function declaration on a
> seperate
> line.
>
> -nbfde, --dont-break-function-decl-args
> Break the line after the last argument in a declaration.
>
> -ncdb, --no-comment-delimiters-on-blank-lines
> Do not put comment delimiters on blank lines.
>
> -ncdw, --dont-cuddle-do-while
> Do not cuddle } and the while of a do {} while;.
>
> -nce, --dont-cuddle-else
> Do not cuddle } and else.
>
> -nfca, --dont-format-comments
> Do not format any comments.
>
> -npcs, --no-space-after-function-call-names
> Do not put space after the function in function calls.
>
> -nprs, --no-space-after-parentheses
> Do not put a space after every '(' and before every ')'.
>
> -npsl, --dont-break-procedure-type
> Put the type of a procedure on the same line as its name.
>
> -nsc, --dont-star-comments
> Do not put the `*' character at the left of comments.
>
> -nsob, --leave-optional-blank-lines
> Do not swallow optional blank lines.
>
> -saf, --space-after-for
> Put a space after each for.
>
> -sai, --space-after-if
> Put a space after each if.
>
> -saw, --space-after-while
> Put a space after each while.
>
> -sbin, --struct-brace-indentationn
> Indent braces of a struct, union or enum N spaces.
>
> -ss, --space-special-semicolon
> On one-line for and while statments, force a blank before
> the semi-
> colon.
>
> -tsn, --tab-sizen
> Set tab size to n spaces.
>
> -ut, --use-tabs
> Use tabs. This is the default.

Hamish:

FWIW this is how those rules differ from what is currently given in the
SUBMITTING file and what is at

http://grass.osgeo.org/wiki/Development#Explanation_of_C_indentation_rules

--- submitting 2008-04-29 09:45:35.000000000 +1200
+++ glynn 2008-04-29 09:45:47.000000000 +1200
@@ -1,33 +1,32 @@
+ -bad
  -bap
  -bbb
- -bli1
+ -bl
+ -bli0
  -bls
- -br
- -cbi0
- -ci4
  -cli0
- -d0
- -di0
+ -cs
  -fc1
  -hnl
  -i4
- -ip4
- -l80
- -lc80
- -lp
- -nbad
+ -l79
  -nbbo
  -nbc
+ -nbfda
+ -nbfde
  -ncdb
+ -ncdw
  -nce
- -ncs
  -nfca
  -npcs
  -nprs
  -npsl
+ -nsc
  -nsob
- -pi4
+ -saf
+ -sai
+ -saw
  -sbi0
- -sc
  -ss
  -ts8
+ -ut

Hi,

as before, my preferences are in submitting; changes to those are seen in
the above diff; and I am somewhat relaxed about this issue.

FWIW I prefer to put { on the same line as the if/for/while as it
tightens up the code vertically. But that is just my personal preference.
For functions I don't mind it on the next line after the declaration.

As far as -cs, -saf, -sai, -saw for space after if,for,while etc. I
prefer not to have that, to me those statements are like f(x), ie one is
an argument for the other not a separate idea. In a similar way to how
"G_some_fn ();" looks bad; just because if/for/while happen to be inbuilt
fns doesn't matter.

for casts I prefer not to have the space as it makes the cast stand out
when you are trying to hunt down a weird bug; a cast is too important a
part of the calculation to quickly have your eye overlook.

2c,
Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

16

Hamish wrote:

FWIW this is how those rules differ from what is currently given in the
SUBMITTING file and what is at
http://grass.osgeo.org/wiki/Development#Explanation_of_C_indentation_rules

--- submitting 2008-04-29 09:45:35.000000000 +1200
+++ glynn 2008-04-29 09:45:47.000000000 +1200

- -bli1

This one really has to change; it's quite common for editors to only
offer a choice of whether or not to indent by one "step". So if you
normally indent by 4 columns for each block, braces are either
indented by 4 columns or not indented at all.

FWIW I prefer to put { on the same line as the if/for/while as it
tightens up the code vertically. But that is just my personal preference.

Right; I tend to prefer quite a lot of whitespace, probably more than
most people.

As far as -cs, -saf, -sai, -saw for space after if,for,while etc. I
prefer not to have that, to me those statements are like f(x), ie one is
an argument for the other not a separate idea. In a similar way to how
"G_some_fn ();" looks bad; just because if/for/while happen to be inbuilt
fns doesn't matter.

If/for/while/etc aren't functions; that's one of the main reasons I
prefer a space in that case, to distinguish them from function calls.

E.g. searching for "\>(" (end-of-word marker immediately followed by
left parenthesis) finds function calls without also catching the test
expression of an if/while/for/switch statement.

--
Glynn Clements <glynn@gclements.plus.com>

17

On Mon, 5 May 2008, Glynn Clements wrote:

FWIW I prefer to put { on the same line as the if/for/while as it
tightens up the code vertically. But that is just my personal preference.

Right; I tend to prefer quite a lot of whitespace, probably more than
most people.

It seems only right to mention here that I also much prefer the opening brace of a conditional block on a line by itself :wink: As well as IMHO making the code look less cluttered and neater, I find the extra space also helps me to see quickly at a glance where the start and end of a conditional block are.

As far as -cs, -saf, -sai, -saw for space after if,for,while etc. I
prefer not to have that, to me those statements are like f(x), ie one is
an argument for the other not a separate idea. In a similar way to how
"G_some_fn ();" looks bad; just because if/for/while happen to be inbuilt
fns doesn't matter.

If/for/while/etc aren't functions; that's one of the main reasons I
prefer a space in that case, to distinguish them from function calls.

E.g. searching for "\>(" (end-of-word marker immediately followed by
left parenthesis) finds function calls without also catching the test
expression of an if/while/for/switch statement.

That's a nice idea - I thought it looked fine (space after if/for/while), but hadn't thought through the reasoning.

Paul

18

Glynn Clements wrote:

> Today the development of GRASS 6.4 has been moved out into
> an own development branch. SVN trunk is now dedicated to GRASS 7
> development which includes major refactoring of the code and
> improvements to data formats etc.

Can we finalise the coding style, so that we can apply it?

This should be done before we start making substantial changes. Once
the code has been re-formatted, it will become much harder to compare
"before" and "after" versions, as any such diff will be dominated by
the formatting changes.

My personal preference is:

indent -bad -bap -bbb -bl -bli0 -bls -cli0 -cs -fc1 -hnl -i4 -l79 \
       -nbbo -nbc -nbfda -nbfde -ncdb -ncdw -nce -nfca -npcs -nprs \
       -npsl -nsc -nsob -saf -sai -saw -sbi0 -ss -ts8 -ut

Descriptions of the above options are given below, although it may be
more clear to just apply the above command to a bunch of files and
look at them.

Others will presumably have different preferences; in which case
please express them sooner rather than later.

Summary of the discussion:

I initially supported -cs (space after cast), but two people (Hamish,
Paul) opposed it, and I don't really care all that much, so -cs goes.

Two people (myself, Paul) supported -sai/-saf/-saw (space after
if/for/while, before the opening parenthesis for the control
expression), while one (Hamish) opposed it, so keep those.

[BTW, it appears that a space after "switch" is compulsory; there
doesn't appear to be a specific switch to turn it off, and -nsai,
-nsaf, and -nsaw have no effect.]

Two people (myself, Paul) supported -bl (opening brace on line after
if/for/while), while two (Hamish, Ivan) favoured -br (opening brace on
same line). Does anyone want to cast the deciding vote here?

--
Glynn Clements <glynn@gclements.plus.com>

19

On Wed, May 28, 2008 at 5:55 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
...

Two people (myself, Paul) supported -bl (opening brace on line after
if/for/while), while two (Hamish, Ivan) favoured -br (opening brace on
same line). Does anyone want to cast the deciding vote here?

Note sure if mine should be the deciding vote here 8others, please!).
I find the opening brace on same line better as files are getting shorter
and since most editors jump to the other brace for a moment to
indicate it.

Markus

20

Hi,

2008/5/28 Markus Neteler <neteler@osgeo.org>:

On Wed, May 28, 2008 at 5:55 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
...

Two people (myself, Paul) supported -bl (opening brace on line after
if/for/while), while two (Hamish, Ivan) favoured -br (opening brace on
same line). Does anyone want to cast the deciding vote here?

Note sure if mine should be the deciding vote here 8others, please!).
I find the opening brace on same line better as files are getting shorter
and since most editors jump to the other brace for a moment to
indicate it.

well, I hesitate to be also deciding vote here, also +1 for -br
(opening brace on same line).

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *