Naming layout guidelines need clarification

[dkbennett]

In the CppCoreGuidelines, NL.10: Prefer underscore_style names, indicates that when there is a choice and no existing style guidelines we should prefer snake_case. As Project Reunion is a new project, I had assumed that I should follow this guidance, but on review it seems it is not preferred and we in fact prefer windows-style, which is summarized concisely below by @dhoehna:

m_ PascalCase for member variables CONSTANTS_THAT_HAVE_SPACES PascalCase for methods and classes camelCase for local variables

We should have clear guidance on naming layout for Project Reunion projects in terms of when camelCase, PascalCase, and snake_case are to be used since there is some ambiguity in the CppCoreGuidelines vs expectations here.

_Originally posted by @dhoehna in https://github.com/microsoft/ProjectReunion/pull/444#discussion_r575474275_

[jonwis]

Coding style and API design guidelines are coming soon.

[Gavin-Williams]

What's the point of using 'm' with member variables? Wasn't there a lot of work to remove this kind of thing from older code representing type. Now we are in the same situation with m indicating membership. It's completely not required in my mind, it doesn't help with anything, it's just naming garbage.

[JaiganeshKumaran]

@Gavin-Williams m_ prefix indicates that it's a private member as opposed to a public member

[Gavin-Williams]

@Jaiganeshkumaran we already know it's a private member, Visual Studio tells us, the use of camelCase (if we use it) tells us, and our understanding of the variable that we are about to use also tells us. And you presume that this is actually something that we need to immediately know when glancing at a variable name.

private List<Transform> Children;
...
Children.Add(t);

Does it help me that every time I read the Children variable, I'm reminded that it's a private field?

m_Children.Add(t); // does the m_ help me here? Does it change a single thing about my intention to add a child transform?

I feel like the use of m_ escalates the 0.1% need of clarification on whether a variable is a private member to we need all private members identified as private members all the time

It's a disproportionate response.