[GRASS-dev] GRASS 7 development started

[Glynn Clements]

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 at gclements.plus.com>