Re: [PATCH 6/6] misc: fix some warnings

[Bruce Dubbs <bruce.dubbs@gmail.com>]

Sami Kerola wrote:
> On 6 June 2017 at 20:17, J William Piggott <elseifthen@gmx.com> 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