Hello, The code used to be 8-tab BSD formatted, and now it seems that 2 space indentantion is being used, or 4 space, or whatever random spacing (sometimes contination lines follow the opening parenthesis of the function above, other times they don't) in both new code and diffs from the old code. If people don't like the current coding style, let's decide on a style, reformat all the code to the new style and keep it consistent. What we have now is making the code unreadable. Thank you! christos
The code has always been somewhat eclectic in style. As it gets more complicated the 8-character indenting has had problems scaling, and I've been using 2-character indenting in new changes when that doesn't involve reindenting much existing code, and sometimes 4-character to insert an intermediate level of indentation without reindenting much else. Reformatting the code to a particular style or indentation level would make it harder to compare versions.
On Oct 4, 12:41pm, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: Re: [tz] coding style for tzcode? | The code has always been somewhat eclectic in style. As it gets more | complicated the 8-character indenting has had problems scaling, and I've been | using 2-character indenting in new changes when that doesn't involve reindenting | much existing code, and sometimes 4-character to insert an intermediate level of | indentation without reindenting much else. Reformatting the code to a | particular style or indentation level would make it harder to compare versions. Well, It is not necessary to change: if (foo) return -1 to: if (foo) return false; I don't any discussion about changing the coding style anywhere. Also: This indentation is clearly wrong, and this is why it runs out of horizontal space: if (doextend && nread > 2 && up->buf[0] == '\n' && up->buf[nread - 1] == '\n' && sp->typecnt + 2 <= TZ_MAX_TYPES) { struct state *ts = &lsp->u.st; up->buf[nread - 1] = '\0'; if (tzparse(&up->buf[1], ts, false) && ts->typecnt == 2 && sp->charcnt + ts->charcnt <= TZ_MAX_CHARS) { for (i = 0; i < 2; ++i) ts->ttis[i].tt_abbrind += sp->charcnt; for (i = 0; i < ts->charcnt; ++i) sp->chars[sp->charcnt++] = ts->chars[i]; i = 0; At least can we have a statement as to what the official indentation of the code is? As far as losing the ability to run diff because of whitespace changes: 1. you can always run diff -bw 2. you do all the whitespace formatting changes in one shot without any other coding changes. christos
Christos Zoulas wrote:
This indentation is clearly wrong
Yes, that indentation-by-16 went off the rails. We should probably fix that the next time we happen to be changing the neighborhood.
I don't any discussion about changing the coding style anywhere.
I've tried to avoid making global style changes even when I thought they would improve the code. Part of this is to avoid unwanted differences (diff -bw does not suffice, unfortunately), and part is out of respect to the previous maintainer, who has a distinct style that I'm loath to discard everywhere merely because it has problems somewhere or because it grates on me. For my own changes, though, I haven't hesitated to use a slightly different style that I think works better; this is not recent practice, as I recall doing that even with code I contributed many years ago.
On Oct 4, 1:35pm, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: Re: [tz] coding style for tzcode? | Christos Zoulas wrote: | > This indentation is clearly wrong | | Yes, that indentation-by-16 went off the rails. We should probably fix that the | next time we happen to be changing the neighborhood. | | > I don't any discussion about changing the coding style anywhere. | | I've tried to avoid making global style changes even when I thought they would | improve the code. Part of this is to avoid unwanted differences (diff -bw does | not suffice, unfortunately), and part is out of respect to the previous | maintainer, who has a distinct style that I'm loath to discard everywhere merely | because it has problems somewhere or because it grates on me. For my own | changes, though, I haven't hesitated to use a slightly different style that I | think works better; this is not recent practice, as I recall doing that even | with code I contributed many years ago. It would have been good to have had a heads up for that. Now I am torn on what to do. Follow a consistent style when I import and have to deal with even more change to the base source, or give up? I doubt it that the long term solution is to have mixed style indentation. As for the long staircases, in most cases they can be avoided and you don't have to go to 2 space indents for that; for example: static struct state * zoneinit(struct state *sp, char const *name) { if (sp) { if (name && ! name[0]) { /* ** User wants it fast rather than right. */ sp->leapcnt = 0; /* so, we're off a little */ sp->timecnt = 0; sp->typecnt = 0; sp->ttis[0].tt_isdst = 0; sp->ttis[0].tt_gmtoff = 0; sp->ttis[0].tt_abbrind = 0; strcpy(sp->chars, gmt); } else if (! (tzload(name, sp, true) || (name && name[0] != ':' && tzparse(name, sp, false)))) return NULL; } return sp; } Can be written as: static struct state * zoneinit(struct state *sp, char const *name) { if (! sp) return NULL; if (name && ! name[0]) { /* ** User wants it fast rather than right. */ sp->leapcnt = 0; /* so, we're off a little */ sp->timecnt = 0; sp->typecnt = 0; sp->ttis[0].tt_isdst = 0; sp->ttis[0].tt_gmtoff = 0; sp->ttis[0].tt_abbrind = 0; strcpy(sp->chars, gmt); return sp; } if (! (tzload(name, sp, true) || (name && name[0] != ':' && tzparse(name, sp, false)))) return NULL; return sp; } christos
participants (2)
-
christos＠zoulas.com -
Paul Eggert