Re: Indentation, tabs, and spaces (was re: [PATCH] support: Implement TEST_COMPARE_STRING)

[Patrick McGehearty <patrick dot mcgehearty at oracle dot com>]

On 11/7/2018 9:34 PM, David Newall wrote:
> On 8/11/18 11:07 am, Joseph Myers wrote:
> > On Thu, 8 Nov 2018, David Newall wrote:
> > > Reformatting makes it difficult to see what was changed using diff 
> > > and so, in
> > Naturally it should be done in a separate commit from any substative 
> > changes
>
> I fear you missed my point.  When looking to see what changed between 
> two versions, bulk formatting changes hide what you need to see.
>
> > *Not* reformatting makes parts of the code hard to read, and hard to 
> > edit
> > (as you need to keep fixing up indentation manually every line when
> > editing code not following the normal style), and in practice the
> > hard-to-read issue gets worse over time as the formatting does not stay
> > consistent with a style people aren't familiar with maintaining code in.
>
> I totally disagree that tabs vs spaces makes code hard to read. As to 
> having to adjust your own practices to follow prevailing style, I wish 
> there was a kinder answer than "bad luck", but there isn't.  I think 
> no three programmers agree 100% on style issues, and that's just 
> life.  I doubt there is more than a tiny minority that love the 
> indenting in glibc, but it is what it is.
>
> I cannot overstate how a terrible idea I think edits are that merely 
> adjust formatting, nor how hard it makes subsequent code analysis.
>
> I've worked as a programmer for more than 40 years, so I feel I speak 
> with considerable experience.  Do not do this.

In addition to the issues mentioned above,
a major reformatting will considerably increase the workload
of those who backport upstream bug-fix patches to earlier releases
that are still being demanded by and maintained for customers.
Even the change-over to modern calling conventions added significant
work when I did a recent update merge. Handling a merge after a complete
reformatting would be seriously unpleasant to contemplate.

Perhaps some of the difficulties of the current inconsistent formatting
might be reduced by using the diff option to ignore differences in blank
space?  I.e. if the only diff between two versions is tabs vs spaces
git diff -b (or whatever option flag is used) will report no diffs.

Another possibility that might require significant code work for git
would be for git blame to be enhanced to 'ignore' formatting only changes
and report the 'most recent logic change' instead 'most recent change'.
After all, as someone else said, the tools are there to work for us.

I'm not saying those are the best ways to go, just brainstorming
on alternatives.

- patrick