Re: INN indentation
Richard Kettlewell <[email protected]>
| Newsgroups | gmane.network.inn |
|---|---|
| Message-ID | <[email protected]> |
On 19/09/2021 13:02, Perry E. Metzger wrote: > Delurking for a moment... > > On 9/19/21 06:26, Richard Kettlewell wrote: >> >> (My personal preference would be to completely ban the tab character >> from source code, enforced with build time tests, since the meaning of >> the tab character depends on local configuration and it is, >> empirically, unrealistic to assume that everyone will share the same >> configuration. > > Git offers the ability to check constraints like this on check-in. That's a good point, although I don't know if you can enable those on GitHub in the same way as a local repo. https://github.com/InterNetNews/inn/blob/main/ci/test would be the place for it if not. > I agree with the notion of banning tabs characters from from source > code. This doesn't of course mean that one doesn't still use the tab key > while typing in one's editor, just that one configures it to indent with > spaces. See, for example: > > https://www.jwz.org/doc/tabs-vs-spaces.html > > for a thorough discussion of the options in the choice space. > > If, however, such a thing is going to be done, it would mean a lot of > whitespace changes to review. Luckily, many modern versions of diff > (including that in git) can be configured to ignore whitespace changes > when diffing, to make review of such modifications easier. That said, > the bigger issue is that large changes like this often break development > branches quite badly, though again, the ability to do > whitespace-indifferent diffs can help somewhat. Also good points. In my view the way to make any change would be to use an agreed script (or one-liner). That addresses both issues as follows: 1) Review can be done by the reviewer reviewing the script and then running it independently to verify that it produces the same result, rather than by attempting to review a giant diff. 2) Long-lived branches, or short-lived branches that happen to overlap the change, can be repaired by running the script, effectively carrying out the same change in the branch. ttfn/rjk