Big projects like GNU classpath, gcj or kaffe have many developers contributing code. Unfortunately each developer has his own preferences as to how the code should look like. This starts with such little things like positioning of parenthesis and usually ends with differences that make the code unreadable for other developers with other preferences.
GNU classpath is currently a real mixture of different coding styles. That mostly comes from the fact that some parts have roots in different projects and their code was never converted. This makes it hard for new developers to join the team and write code following the current coding standard of the project; there are too many bad formatting and code examples. It’s even hard for existing developers that just want to fix bugs; each time they look into some source they see code using a different standard. This makes it harder to understand the code and can lead to more bugs.
The GNU classpath project decided to use the GNU coding standard so that sources would have a more standardised look. There are some tools out there that support formatting like Emacs and GNU indent.
For GNU classpath we have and automatic code re-formatting tool called Jalopy. Unfortunatly it doesn’t do everything as we want it yet and this issue is being worked on. Another great tool for getting consistent source code is checkstyle. With it you can check for many stuff that goes above code formating like checking javadocs and common coding problems.
I’ve setup a daily checker that runs jalopy and checkstyle in a cron job. The output is really BIG. Its currently not advisiable to post it to a public mailing list. I will refine my configuration files for jalopy and checkstyle and post to the GNU classpath developer mailing list soon to get them into CVS to let us all share it. Then we can work on reformatting the code and when the issues highlighted by these tools have reached lower volumes we can post automatic checker mails to a public mailing list.