Stabilize new naming conventions

[ken-matsui]

Idea

• Files/Directories: PascalCase
• Types/Classes: PascalCase
• Variables: snake_case
• Class (non-struct) Member Variables: snake_case_
• Functions: camelCase
• Class (non-struct) Methods: camelCase_

Reasoning/Explanation

• Variables use snake_case since they tend to be shorter than functions.
• Why not the m prefix?
  • We need to use m_ for snake_case and m for camelCase.
  • m_ and m are inconsistent.
  • m_snake_case is longer than snake_case_.
• Class Members and non-members (and struct members) are distinguished by the _ suffix, which is similar to Google's C++ Coding Style.
  • The difference is that we apply this pattern to methods as well.
• Only class members have the _ suffix because they have methods, and within methods, variables/functions and members are hard to be distinguished. (Structs won't have methods. => this is different from Google's)

Steps to apply this new policy

1. Apply Class vs Struct style.
2. Apply the new Class (non-struct) Methods naming convention.
3. Apply the new Class (non-struct) Member Variables naming convention.
4. Apply the new Variables naming convention.

See also

• https://github.com/poac-dev/poac/blob/bca4bbde7c9eaea9245e53807d49c322583bf187/CONTRIBUTING.md#naming-conventions-under-construction
• build: support lib.cc #1035 (comment)
• https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
• https://llvm.org/docs/Proposals/VariableNames.html

[ken-matsui]

This naming convention can be problematic when we want to refer to a member variable via methods:

class A {
    int some_thing_;

public:
    int someThing_(); // ok, but depending on the variable name, it might be difficult to read the connection?
                      // Also, somewhat annoying when we want to grep the original variable?
    int getSome_thing_(); // violates camelCase_
    int get_some_thing_(); // violates camelCase_

[badumbatish]

is this for the cabin codebase itself?

[ken-matsui]

Yes, users can control it via .clang-tidy on their codebase depending on their preferences

[badumbatish]

i'm not sure what to make of these warnings, does any of these warnings violate the naming conventions? Or do I have to go to clang-tidy and add the conventions following the filed issue?

[ken-matsui]

IIRC, that’s from system headers. I think I was passing a flag to suppress that useless outputs, but maybe newer clang-tidy doesn’t recognize it anymore? I’ll take a look, but the important thing here is if you have any violations, you should see errors because all warning on this project will be treated as errors:

cabin/.clang-tidy

Line 3 in 7d31d74

WarningsAsErrors: true,*