This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]