I disagree... Because of the tools we have! If only our regular diff tools were able to work on semantic units then we could maybe be laxer on coding standards

I disagree... Because of the tools we have! If only our regular diff tools were able to work on semantic units then we could maybe be laxer on coding standards. Once again Google got it right in their Go language: there's an official spec as to how formatting should look like and there's a utility, gofmt, which does format the code according to the language's standard way of doing thing and this is a Good Thing [TM]. Coding standards should be directly into language specs and then a "dictator" should mandate compliance with the coding standards before committing (use a hook or whatever suits you) to the (D)VCS. Now of course you should be able to check out and see, in your editor, the code formatted as you prefer to see it. And it should cause no issues as long you re-format according to coding standards before committing. This is all pointless ranting anyway: it all comes down to the same age-old issue that we're using text files to represent source code and that these text files can contain structurally incorrect source code. It's all about the tools. Our tools (editor, (D)VCS, diff tools, etc.) do all really s*ck. As long as we'll be using such inferior tools to craft our code we'd better have sound coding standards. I'm pretty sure Google and their Go's gofmt are on to something. As a side note, OP's rant about chaos that should be reigning king regarding coding standards in a codebase falls pretty flat if you're a Go programming team: the entire Go standard packages have been formatted with gofmt and you'd need something much better than the OP's rant to convince a manager that people shouldn't be using gofmt before committing their code... Once can only hope language-to-come do not only mandate a very precise coding standard in the language's spec but does actually enforce it (e.g. by refusing to compile a source file that isn't properly formatted).