clang-tidy: enforce identifier naming and enable rule for classes.

[fabratu]

During #940 (unifying naming scheme of enums) it became clear, that currently clang-tidy does not enforce the already defined naming conventions. It is not straightforward however how to activate them. There are currently some established practices in NetworKit, which would lead to mixed naming schemes (for example G or G([a-z]*|[0-9]*) as a name for graph-datastructure variables).

The PR includes a first version of a modified clang-tidy file using regular expressions for ignoring some "special" cases of NetworKit. The remaining changes will nevertheless be quite huge anyway, since it includes changes in the API for both C++ and Python. I am not sure, whether this special treatment is the best approach though - so this PR is a starting point to ignite a discussion about how to proceed.

[avdgrinten]

It would be good to add comments to the code that indicate why we need to add these exclusion regexps. For example, why do we need to exclude names starting/ending with underscores?

[fabratu]

Makes sense. I added explanations for all ignored expressions.

Also tweaked some expressions:

• Removed leading/trailing underscores for template parameters. Is currently used in some places, but doesn't seem to be of any purpose.
• Removed trailing underscore for function names. This I think is not used, was just inserted to match the leading underscore.
• Added [a-z0-9]* to member, variable and parameter expressions. There are cases, where multiple instances of graphs or other structures/mathematical symbols are used in one block of code (like G1/G2 or G/Gnew).

[avdgrinten]

LGTM now. AFAICS the PR also enables the check (which was previously disabled), right?

[fabratu]

Yes, it also enables the check.

Maybe it is a good idea (like we did with networkit-format), to enable each check one-by-one in seperate PRs. This way, it would be easier to review and discuss possible problems.

[fabratu]

Changed the scope of the PR and enabled the check for class-naming only (+ required changes in the code).

[avdgrinten]

Don't we need deprecations and aliases?

[fabratu]

Don't we need deprecations and aliases?

@avdgrinten Good point. Most of the current changes concern private structs. Any advise whether they should also be deprecated?

[angriman]

Is this used anywhere? If not it can be removed.

[angriman]

Private structs don't need to be deprecated I think.