Explanation of naming conventions for classes, methods and variables

Question

I'm currently in University and they're pretty particular about following their standards.

They've told me this:

All classes must start with a capital letter

Correct

public class MyClass {}

Incorrect

public class myClass {}
public class _myClass {}

All methods must start with a lowercase letter

Correct

public void doSomething() {}

Incorrect

public void DoSomething() {}
public void _doSomething() {}

all variables must start with a lowercase letter

Correct

string myString;

Incorrect

string MyString;
string _myString;

Yet in my last year of programming, I've been finding that people are using much different rules. It wouldn't matter if it were just a few people using the different rules, but almost everywhere I see these different practices being used.

So I just wanted to know what the reasoning behind the above standards is and why some of these other standards are being used: (are they wrong/old standards?)

1. Most methods I've seen start with a capital letter rather than a lowercase-- Pretty much any of Microsoft's methods I've been using from their imported namespaces. This is probably the most common one I've seen that I don't understand

2. A lot of people use _ for class variables.

3. I've seen capitals on variables ie. string MyString;

I know I've missed a few as well, if you can think of any that you could add in and give an explanation for that would be helpful. I know everyone develops their own coding styles, but many of these practices have reasons behind them and I would rather stick with what makes the most sense.

Thanks,
Matt

Answer 1

standards are arbitrary, like which side of the road to drive on; just do it like they tell you to do it ;-)

Answer 2

There is no valuable reason to choose one coding style rather than an other one.

The most important thing is to agree on a coding style with the people you are working on. And to help you to all agree on a coding style, your professor told you a coding style.

Most of the time, it is just a point of view. So, just follow your professor's coding style if you have to code with the university....

Answer 3

Standards are only standards if they are followed, and every company or institution has their own standards. It is one of the worst parts of programming. :D

Speaking specifically about the leading _. From my experience this is mostly used on variables that are declared private within a class. They are usually coupled with a method to retrieve them that has the same name without the leading _.

Answer 4

I am trying to follow the rules from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries by Krzysztof Cwalina and Brad Abrams

Guidelines in this book are presented in four major forms: Do, Consider, Avoid, and Do not. These directives help focus attention on practices that should always be used, those that should generally be used, those that should rarely be used, and those that should never be used. Every guideline includes a discussion of its applicability, and most include a code example to help illuminate the dialogue.

Also, you can use FxCop to check your compliance with those rules.

Answer 5

Standards help with readability, and therefore improve maintainability. (because when you can read the code faster, easier and more accurately, you can debug and repair it, or enhance it, in less time and with less effort.)

They have no effect on reliability or availability, cause the computer doesn't care what the variables are named or how the souurce code is formatted.

If you code is well-organized and readable, you have achieved the objective, regardless of whether or not it conforms exactly to anyone elses "standard".

This says nothing, of course, about how to handle the environment where "standards" are high on someone's list of developer evaluation tools, or management metrics...

Answer 6

I see logic behind capitalisation of classes and variables; it means you can do things like

Banana banana; // Makes a new Banana called banana

I've been learning Qt recently, and they follow your conventions to the letter. I wouldn't ever follow Microsoft's naming conventions!

Answer 7

The standards I've seen echo what's in the Framework Design Guidelines. In the examples you've stated above, I don't see you distinguishing between visibility (public/private).

For example:

Public facing methods should be PascalCase: public void MyMethod() ... Parameters to methods should be camelCase: public void MyMethod(string myParameter) ...

Fields which should always be private, should be camelCase. Some prefer the underscore prefix (i do) to distinguish it from method parameters.

The best bet on standards is to have your team agree upon conventions up front when the project kicks off, you'll find everything much more consistent.

Answer 8

Coding styles are based on personal preferences and to a large extent the features of the language that you're using.

My personal take is that it's more important to be consistent with a convention than picking the "right one". People can be dogmatic about they're preferred style and things can often delve into a religious war.

1. All classes must start with a capital letter - This goes hand-in-hand with variable naming and helps prevent confusion that would arise if you had both classes and variables named with the same rules. My preference is a capital letter because I'm used to it and it follows the guidelines for my preferred language (C#).

2. All methods must start with a lowercase letter - same goes, although I start my methods with an uppercase character (as per C# guidelines).

3. All variables must start with a lowercase letter - this, I believe, is dependent on you language's scoping features. Often people prefix variables (usually an underscore or a character like "g") to indicate a variable's scope ("g" might mean "global"). This can help prevent confusion where variables have the same names in different scopes. My C# driven preference: all variables have start with a lowercase letter and I use "this." to reference a global variable of the same name where scope is a problem (this usually only occurs in a class's constructor).

I can't let 3. go by without mentioning Hungarian notation (which is grossly misused and misunderstood). Joel has a great article that helped me understand these better.

Answer 9

In addition to the main point, that while any specific standard is essentially arbitrary but it's important to have some agreed upon standard, I'd also add that some standards are ubiquitous enough to have achieved the status of the "correct" way to do things.

For example, in java, class names in professional code are always in CamelCase. I'll qualify the always in saying that your code will compile if you break the standard, and you may occasionally find some open source projects that break the convention as well, but I believe that most people would take that as a sign that the author is not too familiar with the language. Most of your professors guidelines are fairly standard (for java, in any case). Being radically different in this case, apart from annoying your professor, will probably irritate total strangers ;)

It's interesting to me that some languages seem to have taken this standardization to heart, and enforce capitalization to have specific meaning (e.g. Haskell).

Answer 10

The rules you're citing are those used pretty universally in the Java world.

Are you doing Java code at university? If not, it may be that they were previously teaching Java, then switched to C# but kept the naming conventions.

Answer 11

Most people are talking about naming convention style, but there are other things to consider when approaching naming conventions, such as what you actually name a routine.

Routine (methods, functions, and procedures) names should typically by in the form of a strong verb + object, regardless of how you format it. For example:

paginateResponse()

or

empty_input_buffer()

as (respectively) opposed to

dealWithResponse()

or

process_input_buffer()

Both "dealWith" and "process" are verbs, but they are ambiguous and cause any other programmers working with your code in the future to have to consult the actual routine definition to determine what it really does.

"Strong" verbs, on the other hand, as shown in the first two examples, are much more powerful in their descriptive power and really pin down what the routine is doing.

This makes your code easier to read as it is self-documenting and leads to higher levels of cohesion.

Also, as a personal point of style, I try to avoid at all costs using "my" in any name.