Wrong formatting settings clang-tidy in C++ template project

Closes CWG-48

It's been a while since I did active C++ development within ASTRON. But we used to have some standards:

• Class names in CamelCase
• (Member) function names in snakeCase
• Class variables start their name with the prefix its (or their for static class variables)

Insights may have changed, though. @wever should now about current SKA conventions (which are not necessarily ASTRON's conventions).

In team Schaap we use GoogleStyle, which has its own naming conventions. https://google.github.io/styleguide/cppguide.html#Naming

GoogleStyle is on of the SKA style guides too,

@wever the google style is using CamelCase (or PascalCase) for methods. I can add that to the comment or even set is as a default if we want to go into that direction.

@loose For function names do you mean snake_case or camelBack (sometimes named camelCase)? About the prefixes: if we wont to go into that direction we ofc can add that as well but probably should first decide on a (common) style.

I meant camelBack (I thought that was usually referred to as snakeCase).

I think referring to a style-guide can't hurt. Google's is quite nice. (I really like they provide rationales for their choices, so you can see whether their reasoning applies to your organization.)

If there is no ASTRON sanctioned style we can make the default Google-style and hope others will start to use the same style. I really like it when code has a consistent style, that makes understanding it a lot easier.

For what it's worth. Here's our (20 year old!) ASTRON coding standard. coding_standard_C++_v2.1.pdf

Interesting, at that time ASTRON still used CVS ;-) But indeed this document is quite dated and it's not provided to new developers during their onboarding.

I wouldn't be against reviving this document.

We could pick this up in the CI/CD group. Maybe good to discuss within Team Schaap too.

changed this line in version 2 of the diff

Don't we use black for formatting Python code? That tool defaults to a line length of 88.

In team Schaap we this:

# Use line length 79, which complies with PEP-8.
BLACK="black -l 79"

TBH, with indentation of 4, I find a line length of 80 quite limiting. I know that pylint uses 100 by default, and (like I said) black uses 88. Even that is already somewhat limiting. I don't think readability always improves with a lot of line wrapping

I agree that the tools are never 100% great, much better that a programmer. In C++ I tend to use trailing // or clang-format: off for the few parts the tool does not work great.

I still like 80 characters combined with 4 column tabs. IMO when 80 columns becomes too small it quite often means the indention level is high and that might be a sign your function is too complex. (It somewhat depends on the domain, in team Schaap we iterate over 3 dimensional arrays on a regular basis.)

In our python template we use different tools with different settings. One of them is pep8 which indeed uses 79 characters.

changed this line in version 3 of the diff

added 1 commit

• 89ff1995 - Set function case to CamelCase

Compare with previous version

added 1 commit

• e3911dc8 - Fix .editorconfig

Compare with previous version

mentioned in commit 75c686ae

merged