views:

510

answers:

10

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

_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 convey 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
  }
}
+1  A: 

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

kchau
So do you mean, that with variables that have function scope for examples function parameters to append a "l_" at the start of them. Just to clarify?
Chad
+3  A: 

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.

Greg Hewgill
I do this naturally, and never even noticed it till now. +1
John MacIntyre
+3  A: 

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.

Andrew Queisser
A: 

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

Kev
A: 

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.

Jonathan Leffler
A: 

I guess anything is fine as long as it conveys the meaning regarding its use.

Nrj
A: 

I prefer to keep it simple, I use:

 m_varname - Class member variables
 g_varname - Global variables
KPexEA
Yes, i understand. But how about function variables that either have complete function scope or limited scope within a if statement.
Chad
I don't differentiate between them and I never have the same var name used with function scope and limited scope, it tends to make things too confusing.
KPexEA
+4  A: 

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.

Joachim Sauer
A: 

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.

Tion
A: 

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.

smp7d