I can't stand it when braces are not on their own line, it is too easy to miss one when the line is wider than the screen and matching braces by column is incredibly easy.

Class names, and public properties are Capitalized

Parameters camelCase

local variables don't matter as long as they are not capitalized. starting with an _ is also acceptable (to me)

private variables holding the data to a property is the same name as the property camelCased with a proceding _

public class Foo
{
  int _count; 
  public int Count
  {
    get
    {
      return _count;
    } 
    set
    {
      _count=value;
    }
  }
}

The only time i use specific prefix or suffixes are with GUI elements, event handlers and delegates.

User controls are prefixed with an _ and have a suffix indicating the type of control.

Events are suffixed with EventHandler

And delegates are suffixed with Delegate

Tabs as spaces is always better (IMO) than tabs as tabs.

I like to ensure that all parenthesis are explicit (unless the expression becomes unreadable because of it)

I work in .net mostly, switching between VB.net and C#.net, I can not stand VB implicit parenthesis for subs without parameters... myObject.ToString just drives me up a wall compared to myObject.ToString()

When in doubt I try to find it here https://msdn.microsoft.com/en-us/library/ms229002(v=vs.110).aspx

Braces How do you feel about policies that strictly control how you brace your code? For example, would you prefer a policy that strictly requires all braces to be on their own line, or a policy that defines only where to put braces when declaring a class or defining a function, but lets you use your own style inside functions (which may well be to put them on their own lines)? To segway into the next section, how irksome is it to have to conform to using a brace style other than your own? Does it just bother you but you can get on with it, or does it leave a nasty taste in your mouth and make you disgusted at your own code?

If I find the policy to be sane, then I don't have a problem with it. For example: I prefer Allman style, and use it where it is possible, but at work we write Java and Javascript code with the Java variant of K&R style, and I don't really have a problem with it. On the other hand if the policy would be to use Whitesmiths style, or something I find equally unreadable, I probably would have found another job already.

Other I am largely interested in what things you consider most annoying to change about your own style. For example, maybe it would annoy you a little to have to prefix a class with “C” if you are not used to doing that, but how annoyed would you be if you could not use “m_” for members of a class? List, in order from most grating to slightly tolerable, things you would hate to change about your own style if you had joined a company that had a coding standard largely in-conflict with your own.

Variable name prefixes basicly make the code unreadable for me. I usually don't read code properly like text, I just run through it, so for variable names usually I only look at the first 3-4 characters, and the length. (I heavily lean on autocompletion during actual coding for this exact reason, I usually don't know the full names of variables, just how they start.) Because of this, if the first characters are consistently the same throughout multiple variable names, I'm forced to read the code like proper text, which is irritating to me, and much slower too.
Class name prefixes while irritating, I can live with them, but they make harder to find stuff for me (again I usually remember the beginning of the class names, and if all classes start with a C, that doesn't make my life easier). I'm fine with anything else that doesn't involve prefixes.

I don't mind whether brace is on same line or new line, however company I currently work at uses pure-cancer style:

Foo* find (int id)
	{
	for(int i = 0; i < global.size(); i++)
		{
		if(id == global[i].id)
			{
			return global[i];
			}
		}
	}

Notice reverse order inside if() statement. That might have been a problem 2 decades ago but now we have compiler warnings. It looks simply stupid and unintuitive.

There's also a space after function name/call if it contains parameters, but no space if there are no parameters. No IDE in mankind supports automatic formatting for this monstrosity.

In my opinion most important rule when deciding on style is automated formatting. If IDE cannot format your style - it's bad style. Although I do believe braces are better left on the same line. Putting it on a different line doesn't add any clarity - it's not a statement, just formatting, and needlessly wastes vertical space. Indending alone is sufficient to show that "this code belongs to that loop", having separate brace showing same thing is redundant.

Also class/function/method headers. Yet another cancer. I'll sooner die of radiation and chemotherapy at this point.

My company's current style requires to write headers with author name, parameter explanations, etc. I can agree with short function description on what it does and extra information on special cases, but author's name? In BOTH header and code file? It becomes obsolete next day when someone edits it. Then you have 2 different names but neither is the author because someone edited it and didn't change name.

I can work with most styles - my gripes with code tend to be related to how a feature is implemented not what the code looks like.

That being said, the basics:
- tabs instead of spaces if I'm working primarily in the IDE, spaces if I have to look at my code in other editors often; this should be consistent throughout the codebase.
- tabs equivalent to 4 spaces
- no snake_case - PascalCase, camelCase, and scope_camelCase are permissible.
- no class prefixes. IFoo is permissible, but discouraged.
- either put opening braces on their own line or don't, as long as it's consistent
- closing braces always go on their own line
- braces should be aligned with the scope that holds them, not the scope they define
- all control flow statements must include braces (except switch cases, which are obviously delimited by other control flow statements) to prevent mistakes

These ones are optional, but I like to enforce them on myself anyway:
- try to stick to a maximum line length of 100 characters
- if a line goes past 100 characters, it should be split up
- if a function signature or invocation would be split up to maintain the line length, all arguments to the function should go on their own line.
- do not declare multiple variables in the same declaration
- if a template type is long enough to take up significant space or is difficult to remember (eg. std::vector<std::vector<std::pair<std::string, int>>>), create a type alias with a more readable and meaningful name and use that instead

Finally:

// don't do this
auto thing = foo();
if (thing) {
}

// do this instead to enforce that the variable 'thing' can only be used if it's valid
// C++'17 will add syntax to make this work for more than just pointer types
if (auto thing = foo()) {
}

// I saw some id Software code that did this and I'm quite pleased with it
// Yes, it's a pain in the ass, but it makes the code SO much more readable for me.
// I would only do this if I had to "pretty up" my code and didn't think it needed to change much.
float    x    = 0.0f;
ThingFoo foo  = ThingFoo::Null; 

For braces, Allman over K&R, but I can live with either. But there are variants that are just nasty... like all those except Allman and K&R in the table on I particularly detest the so-called GNU style.

Similar for tabs vs spaces where I definitely prefer tabs (because you can adjust them. for example two space indents are too small for readability IMO but quite common and then you're stuck with that...) but I can live with either as long as its consistent. And as long as the tabs aren't used for alignment (instead of for indentation only)... which is plain dumb.

Now variable and class name prefixes... no, NO, NO, NO! And it appears im not alone with that opinion. Especially the "C" for class. It's pointless and unnecessary. Especially when considering the fact that classes and structs are the same thing (even if MSVC would like to tell you otherwise).

But one thing I would flat out refuse to do: block alignment, e.g.

int             foo                 =       10;
char            barf                =      'c';
SomeStupidClass anEven_StupiderName = xyzabcde;

Waste of time, you can't cleanly add new values etc. Just no.

I can work with most styles - my gripes with code tend to be related to how a feature is implemented not what the code looks like.

That being said, the basics:
- tabs instead of spaces if I'm working primarily in the IDE, spaces if I have to look at my code in other editors often; this should be consistent throughout the codebase.
- tabs equivalent to 4 spaces
- no snake_case - PascalCase, camelCase, and scope_camelCase are permissible
- either put opening braces on their own line or don't, as long as it's consistent
- closing braces always go on their own line
- braces should be aligned with the scope that holds them, not the scope they define
- all control flow statements must include braces (except switch cases, which are obviously delimited by other control flow statements) to prevent mistakes

Finally:

// don't do this
auto thing = foo();
if (thing) {
}

// do this instead to enforce that the variable 'thing' can only be used if it's valid
if (auto thing = foo()) {
}

Heh. If I'd make a set of coding rules it would be snake_case for most things, PascalCase only for concepts (template parameters) and UPPER_SNAKE_CASE for defines/macros. Because I think it's just not ok to simply ignore how the standard library looks like. (Or avoiding the standard library because you don't understand it which seems to be very popular in C++).

But a big +1 on if(auto thing = foo())! (Although I dislike the space before the if's opening parenthesis.

Another small detail that would make me happy: foo const * x instead of const foo * x. Because I'd prefer consistent right-to-left order over reading in spirals (think foo const * const x vs. const foo * const x).

I can work with most styles - my gripes with code tend to be related to how a feature is implemented not what the code looks like.

That being said, the basics:
- tabs instead of spaces if I'm working primarily in the IDE, spaces if I have to look at my code in other editors often; this should be consistent throughout the codebase.
- tabs equivalent to 4 spaces
- no snake_case - PascalCase, camelCase, and scope_camelCase are permissible
- either put opening braces on their own line or don't, as long as it's consistent
- closing braces always go on their own line
- braces should be aligned with the scope that holds them, not the scope they define
- all control flow statements must include braces (except switch cases, which are obviously delimited by other control flow statements) to prevent mistakes

Finally:

// don't do this
auto thing = foo();
if (thing) {
}

// do this instead to enforce that the variable 'thing' can only be used if it's valid
if (auto thing = foo()) {
}

Heh. If I'd make a set of coding rules it would be snake_case for most things, PascalCase only for concepts (template parameters) and UPPER_SNAKE_CASE for defines/macros. Because I think it's just not ok to simply ignore how the standard library looks like. (Or avoiding the standard library because you don't understand it which seems to be very popular in C++).

But a big +1 on if(auto thing = foo())! (Although I dislike the space before the if's opening parenthesis.

In my world, UPPER_SNAKE_CASE is ONLY used for macros. Constants are spelled "k_constantName".

I've tried doing Erlang-style in C++ (PascalCase for "variable" bindings, snake_case for everything else) and I think that style belongs in Erlang...

In my world, UPPER_SNAKE_CASE is ONLY used for macros. Constants are spelled "k_constantName".

Note that I said defines, not constants! Also constants are regular snake case to me and a loud hell no to k_ ;)