I don't see the benefits either. I wasn't even aware that this practice existed.
Also: While the 'm' is for "member", what does 't' stand for?

I added a note explaining the reasoning 665e7a3

I believe the first time I saw that prefix it was actually a full the_ and I hated it. Then a week or so later I started realizing that having something to prefix a parameter with saves me brain cycles (I no longer have to think up a name that doesn't conflict with some member variable, and I no longer have to question where the variable came from.) And I started using it. It took me a couple of years before I was using it consistently but now prefer it.

This very much falls into the category of things I didn't expect people to agree with me on, but it's what I use in my code.

Thanks for providing more background on this. To me it sounds though, like the problem that this technique approaches is that of incomprehensibly large functions.
That problem could also be solved by splitting these functions up. Of course that's not always possible, but these exceptions wouldn't rectify a general rule.
Also, in my opinion, the example code you added doesn't support the argument, that a t_ prefix makes the code clearer.

Another note: using the t_ prefix causes unnecessary leakage of implementation details into the public facing API.

My two cents for my preferred style (which goes against the Google standards, and as I recall is kind of Java-ish).

• module variables: prefix underbar
• function parameters: postfix underbar
• local variables: no decaration

It easily lets me be aware of the intended scope of a variable. This has saved by bacon on a number of occasions.

class myClass {
public:
    myClass (int val_)
    : _val {val_}
    { }

    int funct () {
        auto val {_val};
        return val * 2; 
    }

private:
    int _val;
};

I'd also prefer not to use any variable prefixes, as they often makes things harder to talk about (or rather to pronounce). Something like: "Hey, Jeff, we should consider moving this tee-width parameter to local scope". Swapping the [t|m] prefix with an underscore suffix (like Google does it for instance) doesn't have this problem.

Remember to be very careful when prefixing variables with _. It's easy to hit identifiers that are reserved for the standard library / implementation: https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier

My general rule is to just not prefix anything with _, so there's no chance of hitting those standard rules.

I want to add a point here against using prefixes like this:

They make the code less readable. You say on the other hand it will be easier to recognize where a variable comes from / what it's scope is (which would be better readability). But this is not the responsibility of code typing style. The responsibility of making the scope / origin of a variable clear is only on the IDE / editors side (syntax highlighting, auto-highlighting selection, outline views and the like).

So, since we nowadays have editors doing all this for you, I'd say prefixing takes a greater amount of readability than it gives, because editors already do provide the positive effects of prefixing so that only the negative aspects of prefixing stay.

Code doesn't just live in an IDE or code editor. We share code in e-mails, chat programs, supporting documentation, or even printouts. While all of these support some kind of syntax highlighting, that formatting is fixed at authoring time. It doesn't adapt to the readers' expectations, and one developer's visual cue for function arguments is another developer's formatting chosen for locals. Naming conventions certainly help to minimize the confusion.

So while I am all in favor of prefixing function parameters, the t_-prefix and more so, what it stands for ("the") aren't entirely appealing to me. My personal preference is the one I picked up while developing for Symbian: a_, short for "argument". There have been objections, sure, but this convention did make it into several coding standards for teams I have worked with. I can only speculate, but I doubt that a t_-prefix would have been equally successful, if only because it is just too similar to the _t-suffix, that's ubiquitously recognized to mean "type" in C++.

I'm suggesting to keep the prefix for function arguments, but change it from t_ to a_. How does that resonate with you or other C++ developers?

Creeping Hungarian infestation here!
However, my practical experience leans me toward the use of a prefix for formal parameter names.
In the wild there are functions that are of such a number of lines that keeping track of parameter names and their use takes more 'brain cycles': if only they stood out more clearly such as class member variables with prefixes in member functions.

I do not understand the 'They make the code less readable' remark.
This is a platitude in the general but the I cannot dispute it for the person who wrote it.
An obverse case. Just recently I read some new C++ code that had a function with a return statement written as 'return (-1);'. When a reviewer, not me, asked if the parentheses were necessary the coder replied 'it was cleaner code'. Does 'cleaner' imply 'more readable' here?
For me the parentheses make the statement no more and no less 'readable'. (It's just not the C++ way!)
And so it is with formal parameter name prefixes.
void Foo(int a_arg1, int arg2)
However, when looking at code in a function - in or on any medium - that is many screens / pages below the beginning of the function definition one can forget what the the parameter names are: the more parameter names the worse it is.
Adding a prefix will help in this scenario; makes the code more 'readable', more comprehensible.

I prefer the a_ over the t_.

Re: 'return (-1);'.

Definitely not clean code. What is the -1 saying? It should, possibly, be:

constexpr error {-1};   // or whatever
....
return error; 

The benefit of prefixes is: when using something with code completion, typing the prefix will immediately shrink down all available choices to the scope of the prefix (e.g. members or parameters). Depending on your familiarity with the code base, your memory and the intelligence of the IDE this might be a significant benefit.

#11 (comment)

module variables: prefix underbar
function parameters: postfix underbar
local variables: no decaration

This is unnecessarily detailed. Function parameters fall into category of local variables. Thus, simply

int member_;
int local;

This simply solves the requirement 665e7a3:

The point is to distinguish function parameters from other variables in scope while giving us a consistent naming strategy.

No t_ or m_ or other prefixes are necessary. And, variable names remain clear and easy to read, as words only.

Just FYI, the "prefix underbar" option has far too high of a chance invoking undefined behavior.

Prefixing function parameters makes them truly un-readable and difficult to pronounce which is very frustrating for those of us who are verbal in nature. Frankly, prefixes should be used very sparingly. A suffix _ for members is the most that is needed.

Regarding a prefix for arguments (and referring to them verbally) I prefer the a_ over t_ and simply refer to it as "argument whatever" when discussing. For instance, a_name would be referred to as "argument name" when discussing. Works for me.

This was an interesting read. Apologies for nudging everyone with my 👍s.

In 2021 what have you seen in the wild? What is working for teams for this? I am not a C++ expert by any means, I'm just picking it up, but this is something that has bothered me about the language (lots of variables in different scopes and there is mental overhead in choosing member vs local names).

Edit: Had another thought, would l_ (L for local) not be a suitable suffix? Though it unfortunately an ambiguous letter in most typefaces.

In my style there's only one widely-used name decorator and that's m_ as prefix for non-static non-public member variables. Static non-public member variables can get an s_ but since there are usually far less than the first kind it doesn't really matter that much.

Function arguments are essentially local variables and in my mind don't require any decoration. Module or global variables don't need anything either, I prefer the general rule of thumb to make the length of a variable name somewhat correlated to the size of its scope:

For a loop counter or similar that "lives" for three lines of code i is a totally acceptable name. For a module or global variable that can be seen from a bunch of functions and/or classes etc. something like application_startup_timestamp is more appropriate.

Then sometimes I use v_ for non-public virtual methods, and there might be other project specific prefixes for special cases depending on type and/or use, but those don't happen too frequently. In a nutshell, m_ for data members is the only prefix in my style that shows up a lot.

general rule of thumb to make the length of a variable name somewhat correlated to the size of its scope

Oh I quite like that rule and good example with i.