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 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
