Trying to use this literally, the interpretation is: indent with 4
spaces, and don't ever use tabs.
It says: "Four spaces should be used as the unit of indentation. The
exact construction of the indentation (spaces vs. tabs) is
unspecified. Tabs must be set exactly every 8 spaces (not 4)."
If tabs must be set exactly 8 spaces, how can you use that to indent 4
spaces? Only use a tab to represent two levels of indentation? This
part of it is really poorly worded, and who knows what they were
trying to express.
To keep things consistently formatted the only options are to stick
with all tabs or all spaces, and for the formatting to be consistent
among multiple people spaces are the only option otherwise different
tab settings will result in different code formatting.
A huge deal? Nope. That's why we've chosen to keep it simple: always
use 4 spaces.
The problems arise when people don't do things consistently, and then
we end up with others cleaning up formatting while making other
changes and patches and commits become full of irrelevant changes,
making them hard to review, etc. If we all stick to it (and correct
with formatting only commits that don't do anything else) then it's
not a problem.
So: 4 spaces, 4 spaces, 4 spaces. It's that simple.
Yes, people could debate all day, but keeping it on a pragmatic level,
this is all we need.
-David
On Jan 23, 2009, at 2:53 AM, Jeroen van der Wal wrote:
I totally agree to follow a convention but the first line in the
convention
says "The exact construction of the indentation (spaces vs. tabs) is
unspecified.". So there's no need to replace tabs into spaces
according to
the convention.
-Jeroen
On Fri, Jan 23, 2009 at 10:34 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Actually it's just a matter of convention and we chose this one
http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#313
The intention is to get rid of most of all these comments and
changes we
have to do as commiters...
Patch ahead : 800 KB, 14574 lines (not the bigger I did, changing
licence
headers was twice bigger)
Jacques
From: "Jeroen van der Wal" <jvander...@stromboli.it>
Sorry for my late response, I've been away from a pc for a couple
of days.
We've had debates about tabs versus spaces several times and this
quote
reflects my opinion:
"The debate over whether to use tab characters or spaces for
indenting
code
is probably as old as Fortran. In fact, the arguing over this
topic has
led
to many a newsgroup and mailing-list flame war, many whose
intensity far
surpass any Saturday night Quake Area session your thirteen
brother ever
saw.
Well, I'm here to set the record straight on why tabs are a better
choice.
Like good object oriented design, it's simply a matter of
recognizing the
correct abstractions and encapsulating them appropriately...
A tab in this context represents a unit of indentation, which
should be
separate from the "physical" size of the representation of that
unit (on
the
screen). I happen to set all my editors to render that unit as
equivalent
to
4 spaces on the screen (even though the file only knows there is
one unit
of
indentation, the tab character), but you may set your editor to
render it
as
2, 4, 8, or 100 spaces - whatever floats your boat. Point is, I
don't care
how big you want the indentation unit to be, and you shouldn't
have to
care
how big I want(ed) it either. Any decent editor will let you
control how
tabs are rendered, and should preserve them in the file regardless
of how
they were rendered on the screen.
By always using tabs, my code always looks consistent when I write
it and
you can always make it the indentation as big or small you want
it. What
is
important to the notion of a "unit of indentation" is not the size
of the
indents, but rather the position of statements relative to each
other.
Using
tabs all the time preserves that property, but using spaces
unnecessarily
merges the notion of your or my particular visual choice with the
notion
of
relative positioning.
The more important effect of using tabs is that we abstract out
the "unit
of
indentation" and each implement it with whatever number of
"simulated"
spaces we prefer. Later, if I decide my indentation unit rendering
is not
the right size for me, I don't have to go change a bunch of
existing code
to
be consistent nor do you have to even know I changed my mind.
Now, isn't that beautiful? I wish everyone would see this and quit
using
spaces to indent code and, more generally, trying to make coding
standards
that specify such a "personal preference" kind of thing.""
So is this patch really worth the trouble?
-Jeroen
On Thu, Jan 22, 2009 at 8:08 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
If nobody disagree I will do that tomorrow. It will be a massive no
functionnal change.
Jacques
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
I will eventually do that later when the BigDecimal branch will
have
been
merged
Jacques
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
If nobody complains, I will replace *all* tabs by 4 spaces in some
days.
It will be one sole big patch without any other changes
Jacques
From: "Stephen Rufle" <sru...@salmonllc.com>
+1
:)
Jacques Le Roux wrote:
Currently there are 2351 tabs in Java files. We could easily
replace
all of them by 4 spaces. What do you think ?
Maybe we could do the same in XML files, there are 32 786
tabs in
them...
In FreeMarker files : only 563 tabs, in Groovy only 668
JavaScrip files have 242 088 of them, most js files come from
outside...
Thanks
Jacques
