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 Thu, 8 Nov 2018, David Newall wrote:

> I fear you missed my point.  When looking to see what changed between two
> versions, bulk formatting changes hide what you need to see.

So you use "diff -w".  Or diff before and after a reformatting change 
separately, or specify a revision with "git blame" to look at history 
before that revision.

> I totally disagree that tabs vs spaces makes code hard to read. As to having

I'm thinking more of e.g. missing spaces around operators making code 
harder to read, but tabs *do* make diffs harder to read, especially when 
quoted (and mixing tab-indented lines and space-indented lines at the same 
indentation level, more so).

I think "should we fix formatting in existing files to follow GNU style 
better, including for files that originally came from elsewhere (BSD, 
fdlibm) but are now maintained in glibc?" is a separate question from "if 
we adopt spaces for indentation in future, should we change in bulk 
existing files that use tabs?".

Florian noted the possibility of using commit hooks to enforce a 
particular style for new / changed lines, but that would only detect 
problems at the point where someone tries to push to the central 
repository - whereas if you have a uniform style rule for all .c files 
(except maybe for a very small whitelist of files that are generated or 
come verbatim from elsewhere), and it can be verified automatically, you 
can run such verification in the glibc testsuite and so detect issues 
sooner.

(In the case of trailing whitespace, which the commit hooks *do* reject, 
we *did* fix it in bulk in existing files some time ago.)

> to adjust your own practices to follow prevailing style, I wish there was a

With a consistent style in a project, you can set your editor to default 
to the style of that project for files therein.  Once some files, and even 
some parts of some files, have different indentation style from others, 
that no longer works so well, and there is extra work indenting every line 
manually to match the different style in a particular file, or else the 
file gradually gets less consistent (and in practice both occur).

-- 
Joseph S. Myers
joseph@codesourcery.com

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