C++ code styling

[zach2good]

Styling is typically arbitrary and completely down to the maintainers actively choosing a certain style.

There's no functional difference between Allman or K&R bracing apart from whitespace and how vertical you like things, etc.

Thanks to exposure in my day job my styling preferences are changing - in ways that allow us to better support them with tooling instead of fighting them with exceptions, etc.

Const qualifiers

// Current style
// "A string const-ref":
std::string const&

// New style
// "A const string ref":
const std::string&

You can see why I tend to prefer east-const here: https://hackingcpp.com/cpp/design/east_vs_west_const.html

But in terms of what's more widespread and better supported by clang-format: west const is the winner.

Lambda funcs, inline lambdas, etc.

// Current:
// clang-format off
some_func([&]()
{
    // lambda body;
});
// clang-format off

// New:
some_fun([&]() {
     // lambda body;
}

Despite us being Allman braces across the board, tooling simply don't allow us to treat lambdas or inline lambdas as if they were inline allman-style function bodies. If we allowed K&R bracing in this one case, it would allow tooling to handle it, and it would also line up with the one inline-func ruling exception we have in Lua - since Lua requires this sort of syntax.

Storing ptrs

We need to stop. I'm working on architecture things to make this much less painful. We really need to get on top of lifetimes and stop dumping everything into global/extern/static.

Member var naming

I'm a recent convert to memberVar_ instead of m_MemberVar. I'll probably be taking this on in my new code going forward, but won't be enforcing this anywhere. I might refactor some bits this way. It's not like we're consistent with member var naming or casing anyway.

Usual disclaimer

These sorts of things are always up for discussion - IF YOU HAVE A HORSE IN THIS RACE. If you don't compile core (at least) multiple times a week because you're working on it, you probably shouldn't be putting forward your opinions on how it looks.

EDIT: More reading: https://en.wikipedia.org/wiki/Indentation_style

[zach2good]

This is probably encapsulated by this work, which is looking increasingly like it'll become "2025 refresh" 😢

#6263

[zach2good]

Other things I'm considering:

Flattening namespaces:

// Old
namespace utils
{

    // Is force-indented by 4
    struct Thing
    {
    public:
        int member;
    };

} // namespace utils

// New
namespace utils
{

// Is flattened
struct Thing
{
public:
    int member;
};  

} // namespace utils

[zach2good]

As part of the tooling refresh, it's also a good time for us to look up what clang-format comes with Ubuntu 24.04, update using their rules, and then apply over the codebase. We can then start looking to see if we can remove all of those instances of clang-format off etc.