[GRASS-dev] GRASS 7 development started
Hamish
hamish_b at yahoo.com
Sun May 4 06:51:19 EDT 2008
> 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
More information about the grass-dev
mailing list