Coding-Style Poll

I prefer Allman brace style but to be honest, brace style, indentation, tabs-vs-spaces, etc - I can live with all of those. Worst case is I run the code through a source formatter after checking it out, then again before checking it back in. Takes a couple of seconds, no big deal and definitely not worth getting upset over.

"m_" and "g_", on the other hand, stop me in my tracks. I mean if I was forced to use them, or if I encountered code that used them. It's not grating and it's not annoying, it's that they genuinely stop me in my tracks and impact my productivity that much.

I don't work in an environment where anyone is telling me how my code should look, so I haven't had to play that game. But I can say it does irk me sometimes when reading other coding styles on websites (gamedev, stackoverflow, etc). I can get over it, but it sometimes feels like I have to stare at the code longer. Heck, I think I've been known to reformat other people's code when I post replies.

I like braces being on their own line and to line up vertically with their match. I just find this easier to look at. When it is at the end of the line, it feels like i have to hunt for it.

I used to subscribe to the prefix (C, I, m_), but over the years I just found them annoying. I think as soon as I had a class that started with a C or an I (making a double letter), it just looked weird to me (CClass or IInterface). I will occasionally use an underline suffix when using c# and properties when there is a similarly name variable backing up the property, but I try to avoid it when I can.

I also subscribe to the Pascal (or Upper Camel Case) for naming.

bool is_prime(unsigned n) {
  if (n % 2 == 0)
    return n == 2;
  
  for (unsigned k = 3; k * k <= n; k += 2) {
    if (n % k == 0)
      return false;
  }
  
  return true;
}

I think every project/codebase should have a defined style all the way through.

I'm just sooo happy I work in C# where there's basically one universally accepted naming convention and one almost universally accepted formatting convention. Sure, there are differences between projects sometimes, but the differences are typically negligible compared to many other languages.

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.

that's easy. its all about keystrokes (data entry speed) and readability. the more unnecessary keystrokes, the more annoying it is. the less readable it is the more annoying it is. typing takes time. deciphering code takes time. time is money. but unlike money, you only have a finite amount of time - don't waste it.

that being said, it sounds like you've been hired to produce code that conforms to certain formats and coding conventions. it would probably be a good idea if you just swallowed the bitter pill and wrote their ugly code for them. and be thankful you can define your own saner conventions for your own projects.

I'm flexible to what is agreed on and what's already there. Different code style doesn't bother me at all, as long as it is consistent. What's annoying is when it is not consistent. What annoys me is like this:

void foo()
{
    if (true) { // <-- inconsistent braces.
        ...
        if (false)
            do something // <-- no braces gives problem when more than 1 line is needed, and again it's inconsistent.
    }
}

Any prefix, as long as they're consistent, I'm on it, even if it's as silly as prefix "S" for struct. I'll be annoyed if suddenly I see struct without "S" when it is already agreed that we should use "S" for naming structs.

Technically, however, "m_" gave me a problem with IDE. If there's an agreement not to use "m_", of course, as I said, I'm okay with it. But technically, in my experience, "m_" for private properties makes things easier on code completion and realizing on private properties on Visual Studio. Same goes to "g_" or "kVarName". Visual Studio's code completion somehow doesn't make a good order on which is private and which is public, which is global and which is related to the class and order things by that.

But in JetBrains WebStorm with code as sick as JavaScript, it can easily and automatically tell me which is private (semantically) or not, which part of the class or not, even with just a "_" prefix.

that being said, it sounds like you've been hired to produce code that conforms to certain formats and coding conventions. it would probably be a good idea if you just swallowed the bitter pill and wrote their ugly code for them. and be thankful you can define your own saner conventions for your own projects.

It completely depends on the developers I think... I've worked with devs who I can't understand what's going on until I place in some white space, and I've worked with devs who document everything fine.

The best standard I've used is one where an example of test data for parameters is included in a header for each method that has at least a few returns, so it just "made sense" when jumping into any method.

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.

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.

How do you feel about policies that strictly control how you brace your code?

I think it's a good thing to promote a reasonable consistency in the codebase. While good programmers can bounce between any particular coding style, it reduces the cognitive load when looking at unfamiliar code and makes it easier to do searches in the code (although this is more true when trying to remember function names or doing searches like "variable = "). If there's going to be a style guide policy for braces it should be for the all the code written within the company no matter where it is (maybe separations for game vs tools code, like no stl in game but in tools it's okay)

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?

Personally I'm fine with it. Honestly I've probably spent more time coding it styles at work that I had a problem with one way or the other than I have in the style I use for personal projects.

I am largely interested in what things you consider most annoying to change about your own style.

Braces are kind of annoying, but only when first getting used to a new codebase. Indentation policies I've ignored a lot of the time when the policy makes the code less readable (the policy for switch statements at my old job had the switch & cases at the same level which I found an inane way of writing those).

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.

For me it usually has to mostly to do with age of the policies. When I started my last job it had a policy written when C with Classes was how you needed to write reasonable portable code, especially on consoles. It hadn't been updated in quite a while for improvements to compilers or getting the most from C++ or even what had been recognized as C++ best practices. I had a lot of suggestions and input in the updated policies to address these sorts of things when we finally got around to updating the coding standards we used.

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".

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