What's a good naming convention for large-scope function variables?

Question

You can have different naming convention for class members, static objects, global objects, and structs. Some of the examples of them are as below.

_member
m_member

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

But is there any good technique or naming convention for function variables scope that conveys when a single variable has complete function scope or a short lifespan scope?

void MyFunction()
{
  int functionScopeVariable;

  if(true)
  {
    //no need for function variable scope naming convention
  }
}

Answer 1

We tend to use an l_ prefix in our functions for "local." And, that's worked pretty well.

Answer 2

I actually encourage delegating this task to the IDE/editor you use.

No, I'm not actually talking about naming variables, that is still best done by a human. But the underlying task of such naming strategies is to show you which type of variable any one name represents.

Pretty much every IDE worth its salt can define different styles (colors, fonts, font types, ...) to different variable types (instance member, static member, argument, local variable, ...) so letting the IDE tell you what type of variable it is actually frees you from having to type those (otherwise useless) pre- or suffixes every time.

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

Answer 3

One method is to follow the guideline that the larger the scope of the variable, the longer the name. In this way, global variables get long descriptive names while scope-limited things like loop index variable can be as small as single letters.

Answer 4

I use prefixes or special naming conventions on global, static and member variables so I don't have to use prefixes on locals. I prefer having the option of using short local variable names, especially for loop variables.

Answer 5

There's an argument that you shouldn't have 'large scope functions' so there shouldn't be a problem with naming - just use the 'small scope function' variable naming conventions.

Answer 6

The guidance from MSFT and other style guides for private instance fields is _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's shorter, not Hungarian, and R# supports it as the default rule for private instance fields.

I also like it because it sort of obscures the private fields from Intellisense, as it should, since you should prefer to access your public members first. If I want to access the property Name and I start typing "Na" the first suggestion is the Pascal-cased public instance property Name. In the rare cases that I want to access the private field directly this forces me to make a conscious decision to start typing "_", then I get the full list of my private fields in the Intellisense popup.

I have also seen guidance that says it should be _MemberName if it is the backing field for a public property named MemberName (Pascal-case notation prefixed with "_") I personally don't like that because I think the capital M is redundant, adds unnecessary keystrokes and does not add any extra information.

Answer 7

It really all comes down to whatever the style guidelines for the language suggest if there are any.

Answer 8

I guess anything is fine as long as it conveys the meaning regarding 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 I use for class members. The IDE should take care of finding your declaration. If a function is that large and confusing that it becomes a prblem, there is a gretaer issue needs to be addresses.