Name constants with a leading "k" and mixed case

[kostis]

A C++ programming convention, also suggested by the Google style guide and enforced by cpplint, is to name variables declared constexpr or const, and whose value is fixed for the duration of the program, by a leading "k" followed by mixed case.

There are only two files that require changes, one in the main source, which may require some discussion, and one in the test suite, which is uncontroversial, I think. This commit fixes both of them.

[lundgren87]

I've mentioned one case inline as an example, but in general I am not sure why this should not apply to all static/global const-declared variables in that case?

I think there are quite a few more that violate this code standard should we adopt it (which is perhaps the real question?).

[lundgren87]

I fail to understand what the difference between L33 and L35 is?
It seems to me that if one adopts the kMixedCase convention, should this not apply to both?

[kostis]

You have a point there.

My guess is that the cpplint check(s) concern only variables that are used as array indices and are either in camel case (e.g. nThreads) or in snake case (e.g. page_info_size). The checks leave variables such as iter which are not used as array indices unchanged.

[kostis]

My guess is that the cppcheck rule only applies to variables either containing underscores or already in CamelCase but leaves simple variables (e.g. i, n, iter, ...) without complaints.

NB: In case you did not notice this already, the cppcheck rule applies only to variables used in array element accesses, not all variables (so the iter variable is not a good example here).

[lundgren87]

Does the change from page_info_size->kPageInfoSize perhaps conflict with our code style guide?

1. All namespaces, classes, class members, functions, and variables should be in snake_case.
2. “Magic” constants, as well as C-style enumerations that are used as integers should be CAPITALIZED.