10

I've just started using ReSharper (for C#) and I kind of like its code smells finder, it shows me some things about my writing that I meant to fix a long time ago (mainly variable naming conventions).

It caused me to reconsider some of my naming conventions for methods and instance variables. ReSharper suggests that instance variable be lower camel case and begin with an underscore. For a while I meant to make all my local variables lower camel case but is the underscore necessary? Do you find it comfortable? I don't like this convention but I also haven't tried it yet, what is you opinion of it?

The second thing it prompted me to re-evaluate is my naming conventions for GUI event handlers. I usually use the VS standard of ControlName_Action and my controls usually use hungarian notation (as a suffix, to help clarify in code what is visible to the user and what isn't when dealing with similarly named variable) so I end up with OK_btn_Click(), what is your opinion of that? Should I succumb to the ReSharper convention or there are other equally valid options?

Zeke Hansell
  • 952
  • 6
  • 11
Ziv
  • 2,946
  • 5
  • 23
  • 26

8 Answers8

19

You can modify ReSharper to use whichever naming convention scheme you use. It's quite flexible, including customising event handlers, fields, properties, methods with various accessibility levels etc.

Don't let the tool define your standards - use it to enforce your own.

Update: Having said that, at work we use mainly lower camel case for most private things - variables, fields, and arguments. Upper camel case for method names, constants, and properties. Event handlers are named based on the action they represent, rather than something specific to the control - eg HandleCustomerContinue rather than HandleContinueButtonClick. I tried the ReSharper default scheme for a while and actually don't mind it, I'm really not fussed either way.

mjhilton
  • 653
  • 3
  • 9
  • Of course, I really like how it helps me keep my local variables in check but I'm curious as to other people's standards, especially when it comes to event handlers. – Ziv May 22 '11 at 10:59
  • Fair enough, I've edited to give some more personal experience detail. – mjhilton May 22 '11 at 11:14
  • 11
    +1 for "Don't let the tool define your standards" – techie007 May 22 '11 at 19:12
  • "Don't let the tool define your standards" has just become one of my favorite programming quotes of all time. – seggy Mar 23 '12 at 13:09
18

With respect to

but is the underscore necessary? do you find it comfortable?

One thing I like a lot about using the underscore, is that it dramatically reduces the use of "this".

Consider: 

public void Invoke(int size) {
    _size = size;
}

without the underscore, you would have to write: 

public void Invoke(int size) {
    this.size = size;
}

which potentially introduces the subtle error of: 

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

In addition, code completion is cleaner because by just tying the underscore you get a list of only the private fields, whereas with "this" you get a list of everything.

With respect to

usually use Hungarian notation

the Framework Design Guidelines: Conventions, Idoms, and Patterns for Reusable .NET libraries says:

DO NOT use Hungarian notation

Leaving little room for ambiguity : )

Dakotah North
  • 3,353
  • 1
  • 20
  • 31
  • Strictly speaking, if you follow the Framework Design Guidelines, it states that variables that are passed to public methods should be in capitals too, in addition to the method names :) – Surgical Coder May 22 '11 at 12:20
  • pzycoman ... can you please point me to where it states that. A quick look and I couldn't find any reference to using capitals in variables that are passed to public methods. But for example, on P 118 of the second edition, there is an example of where public methods are not using capitals but lower case. "public void Write(uint value);" – Dakotah North May 22 '11 at 12:26
  • 11
    In the case of name clashes I would say that `this.size` is far clearer than `_size`. Using the underscored name does not prevent the subtle error, you can still assign size to itself, though hopefully your compiler will tell you. – edA-qa mort-ora-y May 22 '11 at 14:14
  • 2
    Sure, you can always assign something to itself. The major difference between `this.size` and `_size` is consistency. With `this.size` is that it is optional. For example, if there was another private field called `name`, there is no need to use `this.name` in the code, I could just as easily use `name` without any clashes. Because `this` can be used sometimes, and not other times is why using `this` is inferior. On the other hand, there is no ambiguity with `_` ... – Dakotah North May 22 '11 at 14:23
  • I use a sort of reverse hungarian notation. UserName_txt is textbox that should have the user name, People_cmb is a combobox containing poeple, I find it comfortable when I have a couple of similarly named variable (eg: a list Students and Students_cmb, the alternative is StudentsList and StudentsCombobox which is way too verbose). – Ziv May 22 '11 at 20:01
  • 2
    Ugh...why do people still use the underscore in languages that provide a better way. – Rig Mar 23 '12 at 12:14
  • re: Hungarian notation - sure, in general it should be avoided. But I find it very useful (as do many others) for controls. The only alternative is Ziv's suffixed version which seems to be Hungarian-but-pretending-not-to-be. – cjmUK Mar 23 '12 at 14:13
  • RE: Hungarian Notation please see [Apps vs Systems Hungarian](http://www.joelonsoftware.com/articles/Wrong.html), that is all. – Joshua Drake Mar 23 '12 at 14:16
  • A leading underscore for _private_ fields has been making my C++ code cleaner for decades. I carried that over first to Java, then to C#. It's paid off time and again for making a private member stand out from the crowd of locals and parameters. And if you ever use vim, they still stand out. – Brent Faust Apr 04 '14 at 05:31
  • @DakotahNorth try to explain that "there is no ambiguity with _" to graduated student in 10 years. Would it be something like: "In the age of dinosaurs it was hard to distinguish fields from variables..."? – Vladimir Sachek Jun 30 '15 at 14:22
  • "this can be used sometimes", the same applies to _. It is a matter how you enforce one or another convention – Vladimir Sachek Jun 30 '15 at 14:23
8

Consistency is really the key. That and clarity, i.e. don't be cryptic or try to save typing by abbreviating everything. Intellisense is your typing saver, not cryptic (but short!) names.

richard
  • 3,325
  • 2
  • 25
  • 39
  • 2
    +1: Pick a convention and stick to it. Anything will do (except Systems Hungarian). – Donal Fellows May 22 '11 at 11:34
  • Consistency isn't the only thing. For example, someone can choose a consistent naming conventions for their own code, but if that convention is wildly different from other naming conventions, then when using other libraries ... there will inevitably be inconsistencies. For example, if I choose to use property naming conventions from C# in Java, I will not be consistent with how code is written in all other systems. I could write `order.Size()` (as opposed to `order.getSize()`) but since other libraries use getters and setters my code won't be consistent. – Dakotah North May 22 '11 at 14:33
  • Obviously there should be some intelligent thought behind whatever conventions a person decides to use, but consistency is the most important thing. – richard May 22 '11 at 19:12
  • @DakotahNorth - it makes sense to have a house style, but beyond that, consistency is the key consideration. As long as the convention isn't too off-the-wall, it can be easily picked up by external/new developers. Indeed, it's worth publishing the house style, to remove any uncertainty. – cjmUK Mar 23 '12 at 14:17
7

In C# starting protected or public name with underscore is against Common Language Specification. It's correct only in case of private members.

From MSDN:

To fully interact with other objects regardless of the language they were implemented in, objects must expose to callers only those features that are common to all the languages they must interoperate with. For this reason, the Common Language Specification (CLS), which is a set of basic language features needed by many applications, has been defined.

See: http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Here you can read warning about underscore:

Element names starting with an underscore (_) are not part of the Common Language Specification (CLS), so CLS-compliant code cannot use a component that defines such names. However, an underscore in any other position in an element name is CLS-compliant.

See: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

Protected members are problem because you can inherit from class written in another language.

But maybe it's not problem in your case if you don't need CLS-compilant code.

psur
  • 171
  • 1
  • 5
4

I like the underscores. You know at first glance that the variable is a class member and private.

Sure the IDE can tell you that when you hover the mouse over it, but the "first glance" can't be beat. You know what's a local variable, and whats a member variable with your eyes alone. No scrolling or mouse hovers required.

You can use the "this" keyword but _ is shorter for better horizontal scanability. Descriptive names are usually desired but when something is an established convention it's better to have 1 character. for example using the letter i as the index when looping through an array. Since it's an established convention that i is an index, you get the benefit of scanability without the drawback of wondering what "i" means.

mike30
  • 2,788
  • 2
  • 16
  • 19
1

I agree generally with whats being said by other, however when it comes to tools and tools chains, I am lazy and like an easy life. I find life is often easier to just do it they way They suggest. The reasons are

  • It's easier to install (just go with defaults, even I can hit Enter 20 times and get it going)
  • The bugs have usually be worked out of the default settings, often its the esoteric configuration I set up that exposes a defect for the first time
  • The tool chain vendor probably knows more about it than me, therefore they made it that way for a reason. Who am I to decide the experts are wrong (I consider them experts, because I bought their tool)
  • You will never have to defend the vendors choice by a Manager - "It's what They recommend"
  • The new guy won't bug you with "why" and "It's better that way" - When every answer is "because They decided..."

So my take would be if you can find a valid reason to reconfigure the tools you just spent a fortune on, by all means do it. If you cannot justify making the change, don't.

Keep in mind that each and every change has an ongoing cost (real and hidden) to maintain. The less there are, the lower the cost. For instance - that new guy I mentioned - no changes means he can read their manual. Reconfigure - you have to write the addendum, store it away with otehr stuff, retireve it and get him to read it after reading their manual. Maybe not a problem for a 2 man shop, but what about a 100 man shop?

mattnz
  • 21,315
  • 5
  • 54
  • 83
1

The two rules that you are asking about, underscore at the beginning of the private field names, and method names are generally regarded as the norm in C# development circles. By adapting to those conventions your code will be immediately more understandable to other developers because that is the frame of mind they are used to operating in.

The suffix of Label, RadioButton, etc. for your controls is generally regarded as the norm as well. Frequently multiple controls will exist for a single concept (e.g. a Label and a TextBox), and this suffix is quite useful. True Hungarian notation was abandoned long ago because it has been bastardized into something that does not express its original intent, which was context about the variable not what type, size, etc.

Charles Lambert
  • 2,019
  • 17
  • 18
1

In my case, using camelcase and underscores helps with descriptive (read: long) variable names and code completion. I'm not quite sure how Visual Studio autocompletion works but in QtCreator and to a lesser extent, Eclipse, one can type, for example

sDI

and have it expanded to

someDescriptiveIdentifier

Saves a bit of typing in case you have names like 

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

which I tend to produce when in "descriptive naming mode".

Using underscores I can determine which name I want autocompleted

someDescriptiveIdentifier

or

_someDescriptiveClassMember

Hope my explanation is clear enough :)

Manjabes
  • 171
  • 4