Brent Owens ha scritto:
I thought this was already discussed and voted down?
Hum, if you refer to
http://www.nabble.com/Code-Formatting---Vote-t1278276.html#a3414679
it seems to me most of the people was in favour, with a strong opposition
from David (based on the fact that it makes branch mergin harder, while I
assert exactly the opposite, read later).
Actual changes before this event will be lost in the formatting
changes, and that was the main reason for no auto-formatting.
What? No, exactly the opposite.
On the trunk, every change before auto-formatting is dutifully stored
in the version control, is not lost.
Have you tried doing a diff between branches and trunk? I did: most of
the changes you see in the diffs are formatting related, you won't see
the real changes at all.
But if you reformat both before diffing, you'll see the actual changes.
If we merge now, we'll get both the real changes and the code style ones,
without possibility to say which is which.
Think also about normal commits in the context of the trunk. Programmer A
modifies code, and commits (say A uses spaces for indenting).
Programmer B opens the file to do a fix and it's all ruined in its
editor,
because he uses tabs for indenting. He fixes both formatting and the bug.
Commits. The bug fix will be hidden in the changelog, because of
formatting
changes.
That and it will never please everyone: we all have our own styles.
We also are a team, and we should work as one. How many modules are owned
by a single developer?
If everybody does its own we just end up with a mess.
I like formatting with 2 spaces indent and 100 columns, or 4 spaces
indent
and 130 columns. Does this mean I can freely reformat every file where
I do
some significant change (not one liners) only because "I have my own
style"?
On the other side, if there is an automated formatting tool in the build,
(and since every serious developer does a build before committing),
the code
will always be formatted the same way and only actual changes will
show up
in the svn logs.
Would it be an option to format locally and then merge? Without
inflicting formatting on everyone?
Would that change anything? Once you commit after your local merge you'll
commit both actual code changes mixed in a ton of formatting changes.
aside: I know that an 80 column width will make a lot of people cry.
80 columns is old school and cruel, especially with geotool's long
method and class names.
I hear you, yet if we start discussing about exceptions to the sun
coding convention we'll never end up. As you said, when it comes to
tastes
everybody has its own style.
That's why where I work nobody is allowed to have its own, a coding
standard
is decided up front and personal variations aren't allowed. We spend our
time coding, not reformatting code (the IDE does that for us).
Cheers
Andrea
