I worked with a team for a while which brought in a “tidy” function, and it was very quickly a version-control train wreck: the filter made countless “little” changes to the source-code, triggering what the VCS saw to be a massive-change commit, whereas the code had not “changed.” The VCS wasn’t language aware, and offhand I don’t know of one that is.
The team switched to using PerlTidy as an Eclipse plug-in but only on new code, and even that really did not last long. (The plug-in could tidy-up a highlighted block, which was nice.) Once people got the hang of writing “tidy” code, they simply did it themselves for their new patches and so-forth.
In the name of version-control continuity, there were
two three house-rules:
- Even if it’s ugly or unsightly, leave it alone unless you are actually, meaningfully, changing something.
- Limit the scope of your change to what needs doing to get done the job-at-hand. Don’t make gratuitous source-changes that are not clearly related to the ticket / change-order being worked-on.
- Don’t be clever, e.g. in the name of “efficiency.” Just be clear. map and grep chains, for example, were generally verboten, because that leads to tightly-coupled code that is hard to revise, and so on. Even a “tidy-fied” version of hard-to-understand or hard-to-change code is still ... hard to understand and hard to change. The code was meant to be easily understood “at a glance,” and that entails far more than indentation and capitalization.