All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Mielke <mark@mark.mielke.cc>
To: Larry McVoy <lm@work.bitmover.com>,
	Russ Allbery <rra@stanford.edu>,
	Felix Domke <tmbinc@elitedvb.net>,
	linux-kernel@vger.kernel.org
Subject: Re: Indention - why spaces?
Date: Mon, 30 Dec 2002 18:20:08 -0500	[thread overview]
Message-ID: <20021230232007.GA30238@mark.mielke.cc> (raw)
In-Reply-To: <20021230034303.GA11425@work.bitmover.com>

On Sun, Dec 29, 2002 at 07:43:03PM -0800, Larry McVoy wrote:
> > <http://www.jwz.org/doc/tabs-vs-spaces.html>
> Quouting from that page:
>     That ensures that, even if I happened to insert a literal tab in the
>     file by hand (or if someone else did when editing this file earlier),
>     those tabs get expanded to spaces when I save. 

> If you are using a source management system, pretty much *any* source
> management system, doing this will cause all the lines to be "rewritten"
> if they had tabs.  The fact that this person would advocate changing
> code that they didn't actually change shows a distinct lack of clue.
> No engineer who works for an even semi-pro company would dream of doing
> this.  At BitMover, anyone who seriously advocated this for more than
> a day would be fired.

Disagreeing with that slightly - there is middle ground, but it needs
to be explicit, or at least source file type dependent. For example,
whitespace on the *end* of a line containing text can almost always be
stripped. I've had far more trouble than its worth of designers
submitting code that accidentally included whitespace at the end of
lines. They didn't even *intend* to change the line, or when they made
a change, and restored the original code, they unintentionally left
whitespace on the end. Later on in the development process, this
seemingly insignificant difference becomes significant when two
functional equivalent lines trigger to the source manager as segment
that requires a complex merge operation.

The middle ground takes the form 'this is a common mistake people make
for this specific project, and as a business case, it makes a lot more
sense to quietly handle the situation automatically.' Some design
groups force their source to be put through a mandatory automatic code
beautification/styler process during submission. As the customer, and
as the people directly familiar with the problems they experience, and
the responsibility for their choice, they *should* have the choice to
enable a process such as is described in the above URL (expanding
leading tabs to whitespace on submission).

The alternative, of course, is the choice that Linux takes. If it doesn't
meet the appropriate requirements, it doesn't get submitted.

The source manager is supposed to help you, not hinder you. For very common
situations, where responsibility for consequences can be accepted, the
source manager *should* provide the means to perform transformations of the
source code upon submission.

Firing an employee for suggesting this seems a little extreme... :-)

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/


  parent reply	other threads:[~2002-12-30 23:03 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.f9m4suv.e6ubgf@ifi.uio.no>
2002-12-30  3:33 ` Indention - why spaces? Russ Allbery
2002-12-30  3:43   ` Larry McVoy
2002-12-30  3:47     ` john slee
2002-12-30  4:26     ` Russ Allbery
2002-12-30 23:20     ` Mark Mielke [this message]
2002-12-30 12:28   ` Wichert Akkerman
2002-12-30 12:49     ` John Bradford
2002-12-30 12:57       ` Wichert Akkerman
2002-12-30 13:12       ` Rik van Riel
2002-12-30 13:16       ` Russell King
2002-12-30 13:17       ` Dave Jones
2002-12-30 18:53         ` Emiliano Gabrielli
2002-12-30 19:00           ` Arnaldo Carvalho de Melo
2002-12-30 19:30             ` Herman Oosthuysen
2002-12-30  9:42               ` Zac Hansen
2002-12-30 20:43               ` Felix Domke
2002-12-30 23:26                 ` Mark Mielke
2002-12-31  1:02                   ` Wichert Akkerman
2002-12-30 23:55                 ` Herman Oosthuysen
2002-12-31  2:20               ` Anthony J. Breeds-Taurima
2002-12-31  9:47                 ` Christoph Hellwig
     [not found]         ` <mailman.1041274740.23755.linux-kernel2news@redhat.com>
2002-12-31  5:28           ` Pete Zaitcev
2002-12-31  6:04             ` Larry McVoy
2002-12-30 16:12     ` Larry McVoy
2002-12-31 22:43 Heater, Daniel (IndSys, GEFanuc, VMIC)
  -- strict thread matches above, loose matches on Subject: below --
2002-12-31 17:21 Roberto Peon
2002-12-30  2:29 Felix Domke
2002-12-30 11:28 ` Christoph Hellwig
2002-12-31  8:55   ` Tomas Szepe

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=20021230232007.GA30238@mark.mielke.cc \
    --to=mark@mark.mielke.cc \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm@work.bitmover.com \
    --cc=rra@stanford.edu \
    --cc=tmbinc@elitedvb.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.