On 06/08/2014 08:28, Stephan Bergmann wrote:
On 08/05/2014 10:26 AM, Noel Grandin wrote:Would there be any objections to my running a formatter over the existing Java LO code (with the exception of the newer Android stuff) ? Because at the moment - it has very little consistency - and it appears that at some point in time a tabs-to-spaces conversion was done, but not all the files followed the same tab-size convention, so some of the formatting is now REALLY out.With no mechanism in place to automatically enforce a specific formatting algorithm, code formatted according to that algorithm will over time start to deviate from it again, anyway. Hence, for already well-formatted code, arguably the only effect of such a reformatting is to make it harder to trace through the git history.
Therefore, an alternative approach could be to do a mass reformatting only for code that would truly benefit from it, like code whose broken tabs/spaces indentation has made it become "REALLY out" by now. That would of course be a more laborious commit than a wholesale modification of all *.java files.
Okay (and I understand why people don't want the system messing about with commits), but would it make sense or even be possible (if a formatting cleanup is done) to put a server-side hook that says "this formatting is non-standard, are you sure?". And maybe only for places that have been cleaned up ...
Or maybe I'm exaggerating the negative impact on browsing the git history, but that is at least what I feel after many a uses of git blame.Or another possibility - have client-side hooks available so that those developers *who* *choose* *to* can have the code formatted their favourite way on checkout, and then converted back to standard on commit. In other words it's opt-in rather than automatic (which seems to be what has panicked most people).
Oh - and while it's a trivial issue, it's exactly the same thing - most git repositories DO reformat text on checkin/checkout. it's that (cr)lf thing, which if you don't do it will break a repository that has both Windows and DOS committers. Although that's not an argument in favour of a far more intrusive reformat ... :-)
Cheers, Wol