I'm nowhere near as picky as I used to be.

Usually I use braces and member variable/function names like this:

if (mPosition.y < 0)
{
    doSomething();
}

Except I prefer not to use braces on single line if statements. Not terribly annoying, but I do think it hurts readability a bit.

One exception I make to my normal bracing style is in switch statements. Normally I don't like to use braces around cases, but if I need a variable, then I do it like this:

switch (something)
{
case 0:
    qwer();
    break;
case 1: {
    int a = 0;
    asdf(a);
    } break;
case 2:
    zxcv();
    break;
}

Not only does it save two lines, it keeps the indentation level the same without looking as funky as it does if the braces are on their own lines. But again, I could easily give it up if it went against a project's style standard.

I like the m prefix to differentiate member variables from local variables/function arguments, so it's more clear where the side effects are. And I think it looks nicer than m_ and is slightly faster to type.

Classes, structs and global functions are all upper camel case with no prefixes. I would be slightly annoyed if I had to use the C prefix for classes.

Global variables are prefixed with g, constants prefixed with k, enum values with e. I could easily be talked out of any of those, although I do think global variables should have something to mark them as the necessary evils that they are ;)

Long ago, I used Hungarian prefixes on variable names, but I hate them nowadays.

One thing that really bothers me is excessive use of single-letter variable names. It's ok for x, y, z, one or two loop iterators, and stuff like that. But it can quickly turn unreadable if you have a big equation with lots of them. That's why I like programming better than math/physics :) Use meaningful names so you don't have to memorize what each variable is. Long names are ok, especially on things that aren't used very often.

I like spaces around operators so equations don't get too crowded looking. I'd be pretty annoyed without them.

I don't have much preference on spaces around the parentheses of if statements/loops/etc., but I usually do them like the examples above.

Tabs and spaces have plenty of potential drama. Especially if someone uses a different tab size than everyone else, and makes a big table where everything is aligned with tabs. I have a bit of OCD to make my code tab-independent, where I use tabs only at the beginning of lines, and then use spaces between tokens to align things. So even if you change the tab size, it just shifts the whole block left or right but the alignment remains correct.

As I posted already I don't really care about layout oriented standards. There are some i like better than others but I'll adopt whatever I'm required to with minor grumbling.

More important are standards for the code itsself.
Consistent ways of allocating memory. Consistent ways of using threads (Do we use queues, do we "ban" shared data?) Consistent ways of passing data. Do we prefer pass by pointer? Or reference? Do we prefer to allocate memory and pass it into a function to use like in C or do we let objects handle their own memory? Do we like shared pointers or do we prefer other ways to manage things?
I find all of that matters more than layout but again, as long as it's not insane I don't much care the details.

And then standards for accepting code?
Do we insist on actual proper code reviews?

Do we properly document what the changes are _for_ in source control and do we have one functional change per commit so we can manage them?
How is code deployed? Do we need to write a backout plan for each change in case it fails to work in production...

These things matter more than the detail

I'm always doing

for(int i = 0; i < 10; ++i) {
       doLoopyStuff(i);
}

but I feel adding a line break between the function parameters and the first line helps readability for any function bigger than 5-10 lines :

for(int i = 0; i < 10; ++i) {

       doLoopyStuff(i);
       doLoopyStuff(i);
       doLoopyStuff(i);
}

So should i simply switch to the classic style ??

for(int i = 0; i < 10; ++i)
{
       doLoopyStuff(i);
       doLoopyStuff(i);
       doLoopyStuff(i);
}

The only things that annoy me are being forced to use strict prefixes for the type, over-descriptive variable names and the use of auto (where it does not improve readability). I like to read and type my code in a concise manner.

But honestly, I've been to different companies with different standards and the only thing that tends to frustrate me, is when there are partial coding standards - either we have one or we don't. I generally don't care how I'm forced to code, as long as it's well defined. (of course there are exceptions for pure idiocy)

I can live with the 80-character-per-line limitation

I've also worked on some projects that set a 150 character line length and then made use of it almost every line, which I found way more annoying than a "short" length, since the seemingly ever longer names for things meant most lines did in fact use that length and then still wrap, to the '(', '=' or other "alignment" symbol half way across the screen.

The people I joined there just had a single code window on a 1080p screen. I on the other hand generally have the solution explorer (or similar) panel, wide enough to fit whatever deep folder structure there was, then to have 2 side by side code windows (e.g. the cpp + hpp, or the structure + builder, and such like). I found that extremely disruptive as it messed up my entire workflow.

Id go for a short length any day.

but the one thing that gets my jimmies rustled is when I encounter the following for literally every function.

The formatting or the need for a doc comment that stated nothing useful?

I've taken a disliking for coding styles that then require a large amount of additional code/text to not tell me anything a couple of words could have. Even if the basic starting point was an OK formatting (e.g. doxygen, javadoc, etc. for comments, always use braces, description names, etc.).

The idea of a formatted documentation block that stands out I quite like, its just when there these massive blocks repeating the same thing (and who even reads those later anyway?).

There also often a source of doing 3 or 4 (slow) rebuilds because the style checker found a full stop in a comment out of place. I then very frequently see simple things with just plain wrong comments and names because someone copy pasted to avoid typing so much.

e.g. builders that just set simple fields because of an immutable object rule, and 4 parameter constructor rule. Maybe OK so far if dont have C++ "const" in most languages, but then the field in the actual object, the getter in the object, the field in the builder, the getter in the builder, and the setter in the builder all get full doc comments fully describing the field.

        /**Set the name value used to build MyObject.
         * @param value fieldWithLongName value to set. Must not be null and be at least MyObject.MIN_FIELD_WITH_LONG_NAME_LEN and ... and ...
         * @return This MyObjectBuilder instance for chaining. Not null.
         * @throws NullPointerException if the name was null.
         * @throws IllegalArgumentException If the name did not meet one of the other requirements.
         */
        public @NotNull MyObjectWithAReallyLongNameBuilder withFieldWithLongName(@NotNull final String value) 
                throws NullPointerException, IllegalArgumentException {

            Preconditions.checkNotNull(value);
            Preconditions.check...

            this.namefieldWithLongName = value;
            return this;
        }

And generally such strict rules just seem to be a massive waste of time. I still come across lots of horrible code that was written to the letter of the style guide / checker. e.g. the ability to combine long repetitive names and lambda/stream features to "avoid branches" for the complexity checker to make a 10 line by 100 column solid block, then repeated 10 times for each of the different fields/arrays being processed.