With IDEA, every team member doesn't have to remember every time to use the code formatter. Just check a checkbox and it remembers.

@Leo

> Also the issue with what you call "glorified data> structures" is that they are ultimately not. ...> That's the whole point behind accessors> -- they leave the door open today to easy code evolution> tomorrow.

In a few places, you may need glorified data structures.

But, in all the others, the chance of such code someday evolving into good code is little better than the chance of me someday sleeping with Catherine Zeta-Jones.

> It is sad that we have to type out accessors by hand

Strongly disagree. Accessors are generally undesirable. Combined with dumb data structures, they are the antithesis of good Object Oriented Design. Making accessors easier is a step in the wrong direction.

> > Also the issue with what you call "glorified data> > structures" is that they are ultimately not. ...> > That's the whole point behind accessors> > -- they leave the door open today to easy code> evolution> > tomorrow.> > In a few places, you may need glorified data structures.

In my world, I never need them. Almost every "data structure" I have changes and doesn't stay that way. Life moves on -- things change. The only difference is that lists and arrays tend to stay lists and arrays, but other than that, code evolves pretty predictably. In other words, I am pretty confident predicting that things will indeed <b>NOT stay the same</b>.

> > It is sad that we have to type out accessors by hand> > Strongly disagree. Accessors are generally undesirable.

I'm happy to disagree. I believe accessors are essential to good OO design. Accessors turn data access into functions and functions (without side effects) are almost always more desirable than pure data in my experience.

> I'm familiar with Emerson's quote, but I think the keyword> here is "foolish". Consistency, in itself, is not a bad> thing, and can be very useful, such as not having to learn> to drive a car, any time you're going to drive a new car,> and can instead focus on more interesting things.

Consistency across a codebase isn't a bad thing at all, in fact it's a good thing. However consistency over time without the constant reassessment of your position on the matter as you learn new things is a foolish consistency indeed. The rest of this quote goes on to talk about just that.

To equate this to your car example manufacturers have a consistent way to change gears in a car with a manual transmission. The gear stick is in between the two front seats and you move it through a H pattern to select gears, this is consistent across most (a few cars have the steering wheel mounted paddle shift or steering column mounted stick shift) modern cars. It is NOT the same as changing gears in a model T ford or some other early cars which had levers between legs and all sorts of things. Each car company being consistent over time in this case would have been somewhat foolish.

For the formatting aspect of coding style, it should be fairly easy to establish a process that is transparent for version control and users with different personal coding styles (at least with subversion):

Consider all code in the repository to be formatted according to the GLOBALFORMAT, then the way to go would be1. Check out2. Auto-Format with your PERSONALFORMAT3. Edit Code the way you want4. Auto-Format with the GLOBALFORMAT5. Commit

IIRC Subversion/TortoiseSVN only marks a file as changed, when the content changed, disregarding the timestamp.Since the file comes and goes in the GLOBALFORMAT you could reformat to your likes while working with it and even wouldn't have to "burn" a revision number when you decide not to change the file.

But, as the discussion shows, style is more than format.It's more like ... orthogonal: You can have the one without the other :-)

Coding Style is indeed important. It is also important to be able to check coding style in your code quickly and easily. In SemmleCode (http://semmle.com/) this is done by writing simple object-oriented code queries. Fast, easy, intuitive and reusable.

from Field f where f.hasModifier("public") and not f.hasModifier("final") select f, "Warning: " + f.toString() + " field should be accessed via getters/setters"

This is much easier and more straightforward, than defining AST visitors.