Format Java Code in Netbeans / Eclipse, but save it differently

Question

Hi all,

I asked a related question before, but I guess the root of the question is. Let's say I have 2 developers on the team and they both like to look at code in different formats. One likes the braces to be on a new line and the other doesn't.

The approach I was using before is that anytime we run a build, the code is automatically formatted according to the Java/Sun standards using Jalopy; however, I would like the developers to be as happy as possible. They can change the font size, font color, background color, etc.

If I am currently using the Jalopy Maven plugin to format code, can/should I write a hook to SVN that calls mvn jalopy:format on the project when it's checked in? Is this reliable?

That solution doesn't work 100% because it requires the developer to manually format the source code to their liking every time they open a file that hasn't been formatted yet. I was thinking an IDE plugin would be nice as it could automatically format the source to their liking and then save it as another.

What other options do I have to ensure the code is formatted nicely on checkin?

Thanks,

Walter

Answer 1

Hm.. if you use Eclipse you can do the following: 1. configure the formating you like (Window/Preferences/Java/Code Style/Formatter) 2. configure clean up (Window/Preferences/Java/Code Style/Clean Up), under edit check "Format source code" 3. if a developer has a project he can right click on it and source/clean up

The complete project will be then cleaned with the rules you defined there. So therefore after this he would have his own formatting.

Answer 2

IMHO you are wasting your resources with this. Code format is (between certain limits) a question of taste; howewer, people working as a team should be able to agree on using a common coding style.

Once someone has worked on a couple of projects, (s)he knows from experience that one's brain can learn a new code format in a matter of days; after that, it is as easy to interpret as the earlier favourite. Thus, one stops having one "favourite" code format. So I must note that sticking to a specific code format is a beginner's malady; your team would be better trying to get over it to focus on the development itself.