Variable name comments, can't be merged as-is

[cjbacchus]

No description provided.

[PetrilloAtWork]

I use the same namWHHAAAATT??!? err... yes.

Foo::Foo(int x): x{ x } {}

I am not going to write that in a recommendation. Anyway, underscore names have earned the fame of being provate class members, so even _x is somehow deceiving. Sometimes I use a Python solution (x_), but I am not particularly proud of that neither. I would be ok to grant an exception for a short-scoped variable like in the example.
What do you think?

[cjbacchus]

haha. I'm surprised that works. I know from sad experience that int x = x; is valid syntax and initializes x with garbage.

[PetrilloAtWork]

What about this other answer to your objection: only private data members should need initialisation in constructors.
Heh?
I am actually not confident of enunciating this as a universal law, but I believe it's reliable in most cases.

[cjbacchus]

I normally write this pattern for
struct Pt{float x, y; Pt(float _x, float _y) : x(_x), y(_y) {}};

[PetrilloAtWork]

Are you trying to force the users to always fully initialise the point? and is it your explicit intention to disable a default constructor?
Otherwise, Pt p { 8.0f, 9.0f }; should work without the constructor you described:

struct Pt { float x, y; };

I don't want to focus too much on the specific example, but the questions are general.

---

Edit: according to the current guidelines, that structure would look like:

/// 2D coordinates [cm]
struct Pt {
  float x { 0.0 }, y { 0.0 };
};

[cjbacchus]

Partly it's because I'm an old fuddy-duddy who prefers parenthesis initialization to brace initialization. But also, you don't have to get much more complicated before the ability to have a default parameter, or two constructors taking different arguments, becomes useful.

[PetrilloAtWork]

Somehow in a matrix operation I do consider i, j and k descriptive, or mu, nu, lambda, rhofor tensors, andx, yandz` when there is only one vector around. Do you thing we need to spell an exception out?

[cjbacchus]

I'm worried the original suggestion will have people calling their variables firstMatrixSubscript and so on, so I think it's probably better to be explicit (though could combine with the part where you talk about physics equations)

[PetrilloAtWork]

How about:

Suggested change

	**[E]** Starting private data members with `f` and use CamelCase is **encouraged** (e.g. `double fTrackLength`). Agree, but can we spell this out more / ban starting non-members with `f`. Lots of people seem to be confused about this.
	**[E]** Names starting with `f` and using CamelCase (e.g. `double fTrackLength`) are **encouraged** for private data members, and only for them. Conversely, the use of the trailing `f` for local variables is **discouraged**.

[cjbacchus]

"leading", not "trailing" f, and I don't think you want to discourage camel case for local variables.
Maybe this is clearer with examples: ClassName, FunctionName(), fMemberVar, localVar etc

[PetrilloAtWork]

I feel like we need a example table (plus the load of examples throughout the test, if consistent).
I'll settle for this text and then schedule a table.

Suggested change

	**[E]** Starting private data members with `f` and use CamelCase is **encouraged** (e.g. `double fTrackLength`). Agree, but can we spell this out more / ban starting non-members with `f`. Lots of people seem to be confused about this.
	**[E]** Names starting with `f` and using CamelCase (e.g. `double fTrackLength`) are **encouraged** for private data members, and only for them. Conversely, the use of a leading `f` for local variables is **discouraged**.

[cjbacchus]

you still write that camel case is only for private members. Are you calling thisStyle for local variables by a different name? We might need to clarify the jargon in a table / with examples as well.

[PetrilloAtWork]

I call thisStile drinking camelcase and ThisStyle staring camelcase. I am sure that nomenclature is universal and internationally acclaimed.
But to your point, I get it: you prefer the full rule spelled out.

**[E]** Private data member names are **encouraged** to start with `f` and use CamelCase
   (e.g. `double fTrackLength`). This pattern should be reserved exclusively for such private data member.
  Conversely, public data members and local variables should instead follow the more general guideline
  expressed above (i.e. simple camelCase, e.g. `trackLength`).