1. Here's the Eclipse code formatter settings - format your code with those
2. Never format your code otherwise
3. If one or two lines of code formatted this way are unreadable and you can't rework it, format it how you see fit.
The correct tool is code reviews, to tack his eccentricity back to understandable.
Refuse to submit to pedantic assholes. CC is being a pedantic asshole when he claims "there is or isn't a coding standard"
>Now typical escalations are NG assigns the bug to CC since CC won't tolerate his code changes. NG will reformat a big chunk of CC's code just to piss him off.
NG will reformat a huge chunk of CC's code because he can't tell if it's correct formatted in an odd manner.
You can do weird stuff, occasionally, when it's useful. Trying to do it all the time? No. That's not okay. That's dumping a giant pile of tech debt on a project and basically being a sloppy, unprofessional coder. If he doesn't become more professional, you give him the boot, and DON'T MAKE EVERYONE ELSE'S LIFE SHIT for that dipshit.
I hate working at places that never fire people because they tolerate, and eventually promote CC.
If you aren't the manager though, you are NG in my example, its hecka frustrating. When the CTO (and the author is the CTO of his company) says "There won't be any coding style strictures here" you give the CC guy a weapon to annoy his co-workers and his manager. And yes you should fire him once that personality type is made apparent but counting on the manager to have the stones to make that call is often a losing bet. To give you an example of how passive-aggressive this behavior can become, I knew an engineer who wrote his comments in Klingon. The style guide demanded comments, he didn't feel comments added anything useful over reading the code, he wrote comments in Klingon. What sucked (for him) was when Klingon translators started popping up on the web. Needless to say his rants ceased being private to him.
Hilarity ensued, for very large values of 2.
See StyleCop (for MS languages) for examples where "coding style guides" can go overboard.
You're paying me 6 figures, you can make reasonable guidelines about things and expect professionalism but not mindful, constant compliance with arbitrary rules. It drains self control and concentration to follow huge coding standards with lots of minutia (Always put a contract with X Y Z above every function, always put stupid ass hungarian in front of your variables, etc).
In the medium case its fine, you'll get folks who write code using a 'common' coding style and for the most part switching between them will be not too difficult. I've observed over the years that a noticeable number of bugs will be introduced by people who didn't read the code correctly.
The place it will go off the rails is when you hire 'that guy' (and it always seems to be a guy) who writes lots of code, and it works, but for reasons that only he understands he only writes it on one line. He likes every function to have its own line, that way he can just use the 'down line' command to get to the next function. And he doesn't really comment anything except sometimes in the middle he'll start a comment between the code that does something and code that doesn't. And someone will have a problem and it will be in this guy's code and they will come to you because they can't read that code and they aren't going to check anything in like that.
At this point a number of entirely predictable things happen. Let's name the players, "Crazy Coder" (CC) who has the bizarre style, "New Guy" (NG) who is asked to fix a bug in CC's code, and "Manager Guy" (MG) the person responsible, ultimately, for all the code.
First there is a blow up when NG takes CC's code, runs it through a pretty printer and reformats it into something they can read, fixes it, and then checks it in. CC has a huge fit that their code has been made "unreadble" by NG and they go back, rewrite all the code that had been reformatted including the NG bug fix, except they won't quite get what NG was fixing and so CC's version of NG's fix won't actually fix the problem. Now NG will be have their bug re-opened because their fix doesn't work.
Now typical escalations are NG assigns the bug to CC since CC won't tolerate his code changes. NG will reformat a big chunk of CC's code just to piss him off. CC will rewrite chunks of the system to invalidate previous fixes by NG and others.
Now as the outlier, MG might want to tell CC to 'change' their coding style to something a bit more standard. They won't. They will insist either there is a coding style or there isn't, if there isn't then there isn't a problem, if there is then everyone has to follow it. And the coding style dilemma will be served up front and center.
Coding style requirements become the lesser of two evils.