What is a good naming convention for high-volume function variables?

Question

You may have a different naming convention for class members, static objects, global objects, and structures. Here are some of them:

_member m_member 

or in the case of Java, use this.member .

But is there any good methodology or naming convention for a function variable domain that conveys when a single variable has a full functional area or a short lifespan?

 void MyFunction() { int functionScopeVariable; if(true) { //no need for function variable scope naming convention } } 

Answer 1

We tend to use the l_ prefix in our functions for "local" ones. And it worked very well.

Answer 2

I really recommend delegating this task to the IDE / editor used.

No, I'm not talking about variable names that people still do best. But the main task of such naming strategies is to show you what type of variable any one name represents.

Almost every value of an IDE for salt can define different styles (colors, fonts, font types, etc.) for different types of variables (instance member, static member, argument, local variable, ...), which allows the IDE to tell which the type of the variable actually frees you from having to enter these (otherwise useless) pre-or suffixes every time.

So my suggestion is: use meaningful names without a prefix or suffix.

Answer 3

One method is to follow the instructions that the larger the scope of a variable, the longer the name. Thus, global variables get long descriptive names, while things that are limited in scope, such as a loop index variable, can be like small letters.

Answer 4

I use prefixes or special naming conventions for global, static, and member variables, so I don’t need to use prefixes for local users. I prefer to be able to use short local variable names, especially for loop variables.

Answer 5

There is an argument that you should not have "functions of large volume", so there should be no problems with naming - just use the "small scope" variable name conventions.

Answer 6

A manual from MSFT and other style guides for the private fields of an instance of _memberName (camel case notation prefixed with " _" ). This is also the convention used in the source code of many recent Microsoft tutorials.

I use it because it is shorter and not Hungarian, and R # usually supports it by default for instance private fields.

I also like it because it looks like it closes Intellisense's private fields, as it should be, since you must first contact your public members first. If I want to access the property name, and I start typing " Na ", the first sentence is the property name of the public instance with pascal. In rare cases, when I want to access a private field directly, it makes me make a conscious decision to start typing " _ ", then I get a complete list of my personal fields in the Intellisense popup.

I also saw a guide saying that it should be _MemberName if it is a support field for a public property named MemberName (notation in Pascal-case with the prefix " _ "). I personally do not like this because I think that the capital M is redundant, adds extra keystrokes and does not add additional information.

Answer 7

In fact, it comes down to what a style guide offers for the language, if any.

Answer 8

I think that everything is in order as long as it conveys the meaning of its use.

Answer 9

I prefer to keep it simple, I use:

  m_varname - Class member variables g_varname - Global variables 

Answer 10

I use the same convention that I use for class members. The IDE should take care of finding your declaration. If the function is so big and confusing that it becomes prblem, the gretaer problem should be addressed.