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?

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.

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 :)
–
Dot Net Pro UKMay 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 NorthMay 22 '11 at 12:26

10

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-yMay 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 NorthMay 22 '11 at 14:23

2

Ugh...why do people still use the underscore in languages that provide a better way.
–
RigMar 23 '12 at 12:14

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 NorthMay 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 DesLondeMay 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.
–
cjmUKMar 23 '12 at 14:17

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.

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.

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.

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?

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.

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