One coding style policy, many beautification tools?

Question

Are there any projects that help to show that two code beautification tools are configured to produce identical results?

For example, suppose that a project has mandated a particular coding style. Further suppose that the developers of this project are free to use whatever development environment they feel makes them most productive. This means that several source code beautifier tools will be in play. Further assume that the project's version control repository is not administered by the team, as is the case for many hosted open source projects. This situation precludes having some "check-in trigger" that automatically formats the code. The team would like to ensure that each developer produces code that complies with the "official" coding style. Is there any support for helping them?

Update: "Check-in" triggers are now explicitly ruled-out in the question. Thanks for your answer @Martin, it is a very good solution when the project team has total control of the repository.

Answer 1

An idea that seems reasonable to me is to write a source file that contains at least one instance of each construct of a particular programming language. The file is then sufficiently obfuscated so that no text is in its "beautified position." Such a "master file" would be created for each language of the project.

Transforming a master file with two tools and then comparing the results would clearly show whether the tools produced the same output. A tool configuration would be "certified" as supporting the official style policy if its output is identical to the output of a previously certified tool. Obviously, somebody has to configure and approve the first tool manually.

Is there a project that maintains such a collection of "master files?"

Answer 2

If you're using source control of some sort - you can hook in the 'official' code formatter as part of the check-in process (assuming you can run the formatter from the command line). We have this config using CVS and the Eclipse Code Formatter (obviously for a Java shop).

The added benefit is if you ever need to get into branching/merging - you have a consistent style of code (we also do things like re-order members within classes, etc) so the things that you are diffing are really different - you're not spending hours working through files to figure out they're actually the same - someone has just shifted things around.

Answer 3

We provide a tool (Emacs) which is configured to format to the house style. Developers are at liberty to use whatever tools they like, but will be pulled up if their code does not conform to the house style. Its their choice whether they use the supplied tool or whether they want to use something else and then reformat it back to the house style at the end.

Because everyone is used to it, non conformance to the house style is immediately obvious to anyone that has even a cursory look at the source. In over 15 years I can't recall anyone disregarding the house style past their first two weeks. I can only recall a couple that have thought that not using the provided tool was a worthwhile option.