> (this applies to everyone posting here, as many have explained what they like to do but not how they would be bothered going against that)

I think it's difficult to answer that as an abstract question.
Generally I'm not that bothered, there are things way more important than where braces and upper case letters go.
But it depends on the specifics. Mostly I don't like the coding standards where I work but I accept them and it doesn't really bother me.
But there are just a couple of things I find very hard to comply with :P
I do though, and don't get upset about it.

I think I'd be more productive with the style I'm most comfortable with, but as long as the IDE can support the style properly, it shouldn't be too much of a problem.

For example, I use ReSharper which automatically reformats code on paste, semicolon and closing braces. If I can configure it to match your style, then I can work with it. Same thing with naming, if I can set it up to detect incorrect naming etc, then it's probably fine. It needs to work well with intellisense though. For example, if there's a member named m_someProperty, intellisense should be able to list it when I type m_s.., som.., sp.. (acronym) etc. As long as you have VAX and/or ReShaper, that's typically fine.

An important thing in any coding style IMHO is naming. We've currently have a bunch of issues because of that. Let me give you an example:

There is a very "quite" fight between using "num" or "count" prefix/suffix for, describing a variable/functions that is counting something:

int numPoints = foo.getNumPoints()

vs

int pointsCount = foo.getPointsCount();

and:

enum Colors
{
   Orange,
   Blue,
   White,

  NumColors VS. ColorsCount
};

I was a "num" guy, but in order to simplify searching i now use "count" as it is a suffix and it easy to find realtions to that count (it is easier to find all code that is all abount points if everything is named like this getPoints*())

Additionally you should think about similar cases that happen in your company. In my case we internally have an issue with those pairs identifiers "cycle/step", "voxel/core", "node/object" ect.

@L.Spiro I think most of us are interested in the results. So I just wanted to ping you about that. :)

Don't write a coding standard. Ever. People who write coding standards should be lined up against a wall and SHOT. Over and over and over and over again until everyone, everywhere forever stops writing them.

Why?

Because once you've put cursor to Word document[1], for the rest of time you have to boringly enforce it and have it boringly enforced on you.

Companies are very keen on coding standards and it wastes MASSIVE amounts of time. You spend ages messing about in code reviews with people going "oh, this needs a space here and two there and this line is one character too long (and fixing it will involve you hand re-formatting two subsequent lines..)" and everyone's smug about this because it feels like work and it's BLOODY WELL NOT WORK and then later on the review someone says "Oh hey, why don't you just use this API over here" and you throw away all that code and all the effort in fiddling the spaces into place.

Code layout standards are the sort of thing you need if you have either a lot of spare software engineer time you need soaking up or the kind of engineers better deployed on the task of counting spaces in code than in actually writing it. The first option is unlikely and the second is an environment to leave soon anyway.

Go and write an automated nitpicker / code autoformatter / automated nitfixer instead. Preferably by using an existing one wrapped up with some flags describing the selection of options made in the tedious meetings. And very preferably the latter two[2].

Now you a) don't have to enforce it and b) people don't spend their lives having to try and conform to it. A quick command and now you get nicely formatted code and you're having the machines doing the boring scut work. Which is supposed to be the business we're in but everyone seems to lose sight of that when it comes down to space-counting, bracket-lining-up OCD.

[1] Usually, ironically, a very poorly laid out one which sets off my typographical sensibilities but which for some reason can never, ever, ever be changed[3].

[2] An ex-colleague was horrified when my approach to getting frankly stupid quantities of silly, niggly complaints out of an automated Java style-checker was to write a python script which ingested its complaints, parsed them and ran regexes over the source to fix them. I considered this a set of problems which were hence solved for all time. He seemed to consider it cheating. I wasn't doing the penance properly and never would learn how to write compliant code. So I named it after him...