Sami Kerola wrote:
On 6 June 2017 at 20:17, J William Piggott <elseifthen@xxxxxxx> wrote:
I forgot to mention, the line in question exceeds 80 columns and should
be split again (the line changed in last.c wraps now also).
I would say 80 columns is preferred, but we should not be too strict with it.
Sometimes code does look better when wider, and that's fine.
And the spaces vs tab. Yep, we should prefer tabs but sometimes accidents
happen. Calling these 'wrong' is too strong. This is yet another preference
thing, and if someone notices during review spaces where there should be
tabs then that's a good review commend and should be fixed. But I would
not go so far that existing whitespaces ought to be fixed without a change
to code line where they are.
util-linux $ for i in $(find . -name '*.c'); do unexpand $i > $i- ; mv
$i- $i; done
util-linux $ git diff --stat
Just to throw in my two cents, tabs in source code cause problems unless
you have a comment like:
// vim: noai:ts=8:sw=8
and the emacs equivalent.
I spend a lot of effort aligning source code to make it readable.
Research from the 1980s and early 1990s indicated the best levels of
indentations for readability and comprehension of source code is between 2
and 4 spaces. I personally use 3 characters.
Using tabs with different settings destroys that readability.
IMO, embedded tabs in source code add nothing but problems. Editors can
easily substitute the correct number of spaces when you hit the tab key
and spaces allow the reader to always see the code as the author intended.
However, it is your project and your rules. I am not asking for a change.
-- Bruce Dubbs
linuxfromscratch.org
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
