Question

How would one go about proving to management that a batch reformat of all .java files in a large code base (to place the code in compliance with the company’s coding standards) is safe and will not affect functionality.

The answers would have to appease the non-technical and the technical alike.

Edit: 2010-03-12Clarification for the technical among you; reformat = white space-only changes – no “organizing imports” or “reordering of member variables, methods, etc.”

Edit: 2010-03-12 Thank you for the numerous responses. I am a surprised that so many of the readers have voted up mrjoltcola’s response since it is simply a statement about about being paranoid and in no way proposes an answer to my question. Moreover, there is even a comment by the same contributor reiterating the question. WizzardOfOdds seconded this viewpoint (but you may not have read all the comments to see it). -jtsampson

Edit: 2010-03-12 I will post my own answer soon, though John Skeet’s answer was right on the money with the MD5 suggestion (note -g:none to turn debugging off). Though it only covered the technical aspects. -jtsampson

2010-03-15 I added my own answer below. In response to what does “safe” mean, I meant that the functionality of the Java code would not be affected. A simple study of the Java compiler shows this to be the case (with a few caveats). Thos caveats were “white space only” and were pointed out by several posters. However this is not something you want to try to explain to BizOps. My aim was to elicit “how to justify doing this” type of answers and I got several great responses.

Several people mentioned source control and the “fun” that goes along with it. I specifically did not mention that as that situation is already well understood (within my context). Beware of the “gas station” effect. See my answer below.

Answer 1

If it’s just reformatting, then that shouldn’t change the compiler output. Take a hash (MD5 should be good enough) of the build before and after the reformatting – if it’s the same for every file, that clearly means it can’t have altered behaviour. There’s no need to run tests, etc. – if the output is byte for byte the same, it’s hard to see how the tests would start failing. (Of course it might help to run the tests just for the show of it, but they’re not going to prove anything that the identical binaries won’t.)

EDIT: As pointed out in comments, the binaries contain line numbers. Make sure you compile with -g:none to omit debug information. That should then be okay with line numbering changes – but if you’re changing names that’s a more serious change, and one which could indeed be a breaking change.

I’m assuming you can reformat and rebuild without anyone caring – only checking the reformatted code back into source control should give any case for concern. I don’t think Java class files have anything in them which gives a build date, etc. However, if your “formatting” changes the order of fields etc., that can have a significant effect.