Util-Linux package development
 help / color / mirror / Atom feed
From: Ruediger Meier <sweet_f_a@gmx.de>
To: Bruce Dubbs <bruce.dubbs@gmail.com>
Cc: kerolasa@gmail.com, J William Piggott <elseifthen@gmx.com>,
	"util-linux" <util-linux@vger.kernel.org>
Subject: Re: [PATCH 6/6] misc: fix some warnings
Date: Thu, 8 Jun 2017 01:39:23 +0200	[thread overview]
Message-ID: <201706080139.23893.sweet_f_a@gmx.de> (raw)
In-Reply-To: <5938335F.9090108@gmail.com>

On Wednesday 07 June 2017, Bruce Dubbs wrote:
> 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.

IMO it is no problem to write nice looking code if you don't "mix" tabs 
and spaces. Distinguish between indentation and alignment.

So I use these rules which do not conflict with kernel coding style and 
tab-width=8:

  1. tabs for indentation level only (same as the previous line)
  2. spaces for alignment only

That's why in this particular case I've made one tab for the indentation 
and 14 spaces for the nice looking alignment. Though usually alignment 
is nonsense anyways, so I could have better just used one more 
indentation (one tab) instead of that 14 spaces. But I would never use 
1 tab and 6 spaces to let look like 14 spaces. This would have also 
satisfied the 80 char limit without adding another ugly line break.

BTW we have many lines in the our code which are more than 80 chars when 
assuming tab-width=8. That's why I take it as de-facto standard to 
count the line length assuming tab-width=4.


> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



  reply	other threads:[~2017-06-07 23:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01  1:08 [PATCH 0/6] minor last minute fixes for v2.30 Ruediger Meier
2017-06-01  1:08 ` [PATCH 1/6] tests: grep's short option -A is more portable Ruediger Meier
2017-06-01  1:08 ` [PATCH 2/6] tests: avoid diff of diffs Ruediger Meier
2017-06-01  1:08 ` [PATCH 3/6] build-sys: fix library order when linking Ruediger Meier
2017-06-01  1:08 ` [PATCH 4/6] tests: use stdbuf when stderr and stdout is randomly ordered Ruediger Meier
2017-06-01  1:08 ` [PATCH 5/6] tests: handle non glibc error message for fallocate Ruediger Meier
2017-06-01  1:08 ` [PATCH 6/6] misc: fix some warnings Ruediger Meier
2017-06-01 18:50   ` J William Piggott
2017-06-06  8:10     ` Ruediger Meier
2017-06-06 18:18       ` J William Piggott
2017-06-06 19:17         ` J William Piggott
2017-06-07 15:27           ` Sami Kerola
2017-06-07 17:09             ` Bruce Dubbs
2017-06-07 23:39               ` Ruediger Meier [this message]
2017-06-08  5:26               ` Bernhard Voelker
2017-06-01  7:52 ` [PATCH 0/6] minor last minute fixes for v2.30 Ruediger Meier
2017-06-01  8:55   ` Karel Zak
2017-06-01  9:15     ` Ruediger Meier
2017-06-01 10:32       ` Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201706080139.23893.sweet_f_a@gmx.de \
    --to=sweet_f_a@gmx.de \
    --cc=bruce.dubbs@gmail.com \
    --cc=elseifthen@gmx.com \
    --cc=kerolasa@gmail.com \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox