5

There seems to be divided opinion on this subject, and I wanted to get people's insights on whether they've found using underscore prefixes and suffixes to be helpful with coding or not.

You know, code like this:

class MyClass
{
  private int _someInteger;  // some advocate local vars prefixed with underscore

  private void DoSomething(bool someBoolParam_) {...} // and params suffixed_...
}
code4life
  • 363
  • 3
  • 9
  • 4
    The prefix is common; I've never seen the suffix. In the end, your shop standard is the one that will prevail. – Robert Harvey Jul 11 '13 at 03:09
  • @RobertHarvey the suffix is commonly used in Java for construction arguments that have the same name as the field: `class X { public X(int field_) { field = field_; } private int field; }`, I prefer my member variables with `m_fieldName`, but that is just me. – Bob Fincheimer Jul 11 '13 at 04:17

4 Answers4

10

I hate noise in code that merely restates what is or should be obvious. Silent noise like leading or trailing underscores is annoying. Noise that destroys readability, like 'm_x' or 'xParam' or 'getX' is worse.

If you have so many variables in scope that you can't remember which are local and which are class members, you have too many variables in scope. Either the method or the class should be divided. Probably both.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
  • So...like what I said but with a lot less noise. :) – Erik Reppen Jul 11 '13 at 05:33
  • 2
    I agree on "noise" generally, but I disagree that a special prefix for class members belongs to that kind of noise. Even in not-too-big classes with small functions IMHO such a prefix improves code readability a lot. We used that "_" convention for about 10 years, and every time I see code which has no such convention I struggle a lot more to understand what the code does, if it has side-effects or depends on non-local state. – Doc Brown Jul 11 '13 at 06:00
  • 1
    Even if the class has a lot of members, the number of local variables and parameters in any function should be small enough to be memorable. – kevin cline Jul 11 '13 at 08:07
  • But with using the _ prefix you don't have to find anything "memorable". You already know what it is without thinking about it because of the prefix. That's a big gain in my book. I totally disagree that it is noise. It is really useful information that is very non-intrusive. Although, the choice of just a _ prefix in a C-family language is particularly bad since that violates standard C rules. m_ is far better. – Dunk Aug 18 '14 at 13:57
  • @Dunk: the idea is that if I even need that '_' to know what 'it' is, the method is already too complex. The only unprefixed names in scope are either method formal arguments, local variables, or class members. The total cardinality of the first two sets should be small enough that an '_' prefix is completely redundant. – kevin cline Aug 18 '14 at 22:12
  • @kevin:I don't deny what u r saying. I'm looking at some of our code now. For the most part the methods are small and easy to read. However, nice as it may be to think that all the code can be written that way, the problem of error handling raises its head. Even for fairly small methods, error handling makes it more complex beyond what you described. Also, while looking at the code I realized that I never needed to look at the method signature. Having the m_ let me go straight to the logic in the code. IMO, being able to do that without stopping at the signature makes the code more readable. – Dunk Aug 19 '14 at 16:22
  • 1
    A prefix is information. Information is the exact opposite of "noise." By this logic we should name all of our variables x, y, and z. There should be so few of them it it's easy to tell what they mean. If you can't tell what they mean, you just have too many. – Scott Hannen Jan 27 '20 at 20:14
8

My C# team use underscore prefix for private members, as it works very well with Intellisense because while coding you can type underscore and filter out everything but private members.

For the parameter suffix, I have never seen that style in C#. In C#, parameter names are a part of public visibility so suffix will be visible to class consumer as well. Discriminating style between the naming convention of public and private method's parameters will make it more confusing.

In .NET Framework, Camel-casing is recommended for parameter name.

tia
  • 965
  • 5
  • 9
2

From a c/c++ point of view

Prefix underscores are only safe with lower case variables, and even then double underscores are reserved

Suffix underscores are always safe, but lead to very ugly constructions like member_->pointer or member_[3]

Martin Beckett
  • 15,776
  • 3
  • 42
  • 69
0

I'm of the opinion that style conventions should only be relied on to make the nature of a thing clear when naming well and applying the principle of least astonishment isn't quite enough.

So in JavaScript for instance capitalizations helps us with the following:

function plainOlFunction(){...
function ClassLikeConstructor(){...

I consider that reasonable usage of a convention because functions can be used as class-like construct that builds instances or methods. Knowing the intent right off the bat is helpful.

Likewise in Java, C#, and I assume C++ classes get capitalized so we know the difference between:

SomeClass.someStaticMethod();
someInstance.someInstanceMethod();

The reason I'm shy about excess style conventions, however, is that a lot of devs take them as license to be lazy about naming. I've worked under the guy whose parameters were all demarcated by p_ with no name after the p_ exceeding more than 4 characters. And his funcs started with f_, etc... Reading his code could be Hell. (hard to give the guy a nasty code review though since he also started the company)

So why _somePrivateField? If you're in the TransactionManager class, it should be pretty obvious that transactions is going to be a private field where all the transactions are stashed. It might be a local var or a param but usage and context should make that pretty clear.

Why someParam_? You should really know what the params of the function you're dealing with are unless somebody's gone and put way too many to easily remember (more than 4 is pushing it IMO). So in that case the necessity of param identification is really just an enabler of excess param use where data structures probably should have come into play or there needed to be more than one method.

So this?

function screwTheNextGuy(
    p_ew,
    p_bleah,
    p_yuck,
    p_ick,
    p_why,
    p_RUcRius,
    p_ugh,
    p_drlord,
    p_noob,
    p_nomore,
    p_coderage
){...

or this?

function makeTheNextGuyHappy( relatedSetOfValues, anotherSetOfValues ){...

Another common convention I disagree with is separating methods from non-methods somehow. Why do we need that when spoken language allows us to distinguish noun from verb? Do we need a hint to know if it's public or private or should that again be fairly obvious from the perspective of anything you wouldn't need to expose being private?

More specifically on the subject of underscores, important things to check for are the conventions of whatever language you're in because a lot exist. Single underscore prefix is popular for private vars but also for an include-like file and the same often applies to an object representing that file. I would generally never touch double-underscores for common usage since they represent magic vars, constants, reserved names, do-not-touch thingies and god knows what else typically. Mostly I use them as separators to indicate a style convention in the first place. For instance, that I mean $_jQueryObject rather than $phpDevWritingJavaScriptVarNames. So yes like that silly p_ but with a real name on the right of it.

The post-param underscore is definitely kind of odd. We read left to right so that would actually be fairly easy to miss on a quick scan. I wouldn't use that if I thought a style convention was needed.

As a general rule I think it's best to use style conventions sparingly and to make sure that when you establish conventions that you're thinking about the next guy as much as yourself because nobody should have to remember what p_fg and p_deo were supposed to be at line 500 of an enormous function with a dozen parameters. That they're obviously parameters isn't half as helpful as getting an idea of what values they hold.

Erik Reppen
  • 6,243
  • 31
  • 34