httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: cvs commit: httpd-2.0/server util_filter.c
Date Thu, 20 Sep 2001 10:30:19 GMT
> That is complete BS.  We have a long standing tradition of NOT making
> commits just to follow the code style.  There is no need for a vote, because
> this has been discussed to death and formatting only commits have been
> vetoed in the past in every thread that they come up in.  Review the archives
> for Roy and Dean's opinions of formatting changes.  They are completely
> bogus, and just serve to make CVS hard to use.

I don't know what you are talking about.  Any code in our repository that
does not match our style is a bug waiting to happen and will be reformatted
as soon as I get around to it [otherwise known as "never"].  Readability of
the code IS a goal of the httpd project.  Under no circumstance will there
ever be a freeze on changes that make the code easier to read.

There does not exist any longstanding opinion that such reformats are bad,
simply the longstanding opinion that Dean believes in the one true tab width
and too many people are too lazy about tabs to keep them consistent within
a file.  This doesn't change the FACTS that tabs don't survive cut and paste
and often get mangled in the mail and cause the CVS commitlogs to be
misaligned if some lines begin with tabs and others begin with spaces.

The only rule we have is to not make reformats in the same commit as changes.

The general guideline is that new/modified code within an existing file
should match the tab/space usage of the code around that being modified,
for the simple reason that it makes the cvs log easier to read and doesn't
piss off the person who spends most of their time maintaining that code.

The other general rule is that reformats should take place before major
releases, rather than after them, because otherwise context diffs from our
users get hosed.

None of this is ever necessary in *my* code, because I am not lazy about
following the style guidelines.  Anyone who commits code that doesn't follow
the guidelines has no say in how many times it needs to be reformatted in
the future, for the same reason that people who aren't willing to write
documentation have no vote on its contents.

....Roy


Mime
View raw message