Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I take a good deal of criticism from other programmers due to my use of full proper casing for all my variables. For example, your typical programmer will use employeeCount for a variable name, but I use EmployeeCount. I use full proper casing for everything, be it a void method, return method, variable, property, or constant. I even follow this convention in Javascript. That last one really rustles people's jimmies.

The typical reason given as to why I shouldn't follow this "non-standard" casing convention is because full proper case should be reserved for properties and void methods. Local variable and methods that return a value should have the first word in lowercase like int employeeCount = getEmployeeCount().

However, I don't understand why.

When I question this, it seems that I just get an arbitrary answer of that's the standard. Whatever the answer is, it usually always boils down to That's just the way it is and I don't question it. I just follow it.. Arbitrary answers are never good enough for me.

Ever since my early days of programming Excel 97 macros with the Office IDE, I've never needed a casing convention to tell me whether or not something is a local variable or property. This is because I've always used a very intuitive naming convention. For example, GetNuggetCount() clearly suggests a method that goes somewhere an gets a count of all the nuggets. SetNuggetCount(x) suggests that you are assigning a new value to the count of nuggets. NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"

So here's the tl;dr;: What are the objective, logical, non-arbitrary reasons to use lowercase for the first word in your variable or return method?

Edit: For MainMa

Replace this code with the first code sample in your answer and see how well your argument holds up:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}
share|improve this question
3  
If they were in upper-case there would be someone else asking why aren't they in lower-case... –  m3th0dman Jun 19 '13 at 19:14
9  
wouldn't it be nice if our all-powerful IDE's could have a plugin that mapped our own personal preferences for stylistic issues like this and allowed us to use them but behind the scenes, for the "real version" of the source file, applied the "project's" style semantics. It is entirely a visual issue until you need to audit the official file version. just dreaming... –  KenK Jun 19 '13 at 19:24
43  
Unfortunately for you, the actual and valid reason is "because it's the standard". It pays for people in the same team to follow the same code style standard. If you fail to see why, then maybe you should ask another question: "why are standards useful?" –  Andres F. Jun 19 '13 at 20:02
3  
I've always assumed that developers settled upon camelCase because it looked kewl. There's no 'objective' reason for camelCase itself above PascalCase. I personally find PascalCase (like your example) to be much easier to read, and use it in most places other than JavaScript, where I keep with camelCase so I wont miss out on party invitations. –  GrandmasterB Jun 19 '13 at 21:34
4  
Research into Advantages of Having a Standard Coding Style It doesn't really matter what the standard is, just that it is followed. –  Mr.Mindor Jun 19 '13 at 21:42

11 Answers 11

That naming convention is often used when people want to be able to give a variable the same name as its type. For example:

Employee employee;

Some languages even enforce that capitalization. This prevents having to use annoying variable names like MyEmployee, CurrentEmployee, EmployeeVar, etc. You can always tell if something is a type or a variable, just from the capitalization. That prevents confusion in situations like:

employee.function(); // instance method
Employee.function(); // static method

Also, in English, nouns are not generally capitalized, so you can't really claim your capitalization is "proper."

So what does that have to do with your situation? You obviously have no trouble reading your own code, but by keeping things as consistent as possible, you reduce the mental workload of anyone else needing to read your code. In coding as in writing, you adjust your style to match the readers.

share|improve this answer
1  
Note that the problem still exists in the language used by the OP, since properties are capitalized (of course, properties can be prefixed by this., which avoids the confusion; local variables can't have such prefix). –  MainMa Jun 19 '13 at 18:34
    
Karl: In .NET, you can say Employee Employee and VS manages the scope perfectly. In .NET, you cannot have an instance method and static method in the same class with the same name and signature. Lastly, semantics on the word "proper". What should I use in its place? I can't say "uppercase" because that suggests the entire name is uppercase. How about full camel? @MainMa: In .NET, I do this all the time: class x { int i { publix x(i) { this.i = i; } } }. Not sure if that's what you were addressing or not. –  oscilatingcretin Jun 19 '13 at 18:48
17  
Employee Employee works, but I'll argue that it is more confusing to a human reader than Employee employee. The latter looks like two different things. The first looks like needless repetition. –  Jamie F Jun 19 '13 at 19:47
12  
@oscilatingcretin Exactly: "assumes that the reader understands the underlying framework..." I like to read JavaScript, Java, C#, C++, and others and translate the code in my head. I don't like needing to keep thinking "Oh, this language's compiler can deal with x." while I'm just trying to get the meaning of the code. –  Jamie F Jun 19 '13 at 19:52
1  
Note that employee.function() could also be a static method, if the language allows calling static methods from an object (like Java does). The compiler gives a warning, but it is allowed to do that. –  Uooo Jun 20 '13 at 4:30

There isn't any. It is what most people do, so it has become the standard because that is what everyone does. A lot of literature follows this convention so people picked up the habit.

The convention isn't as important as the consistency across the code. As long as everything is named in a consistent manner so that I can tell what things are from looking at them, it doesn't really matter whether or not the first letter is capitalized or not.

I would find it jarring to come across code written in your manner and would say that I don't like it. But that is a matter of style.

Now if you are doing this in the workplace, it would be better to code in the style of the team so that the code remains consistent everywhere. Rather than having your code be different than everyone elses.

http://thecodelesscode.com/case/94

share|improve this answer
3  
I wish most programmers were like you. Many are questionably passionate and/or dogmatic about following the casing standard that I've mentioned. –  oscilatingcretin Jun 19 '13 at 17:36
3  
@oscilatingcretin You might end up being as passionate and/or dogmatic once you've worked on code that's full of var m_someVariableID = GetVariableValueId(). Especially if you have to do it without autocompletion support. –  Tacroy Jun 19 '13 at 17:39
7  
If you are on a team, following that teams standard is important. Note, however, that many programming languages have de facto standards which you should try to follow, when creating a new project where the team has no standards (or where the team has deferred to you to set them). If you aren't sure what coding convention to use, following the convention used by either the primary language vendor or the included framework is preferable to your own standard, unless you can justify your standard. –  Brian Jun 19 '13 at 17:44
2  
@Schleis good update, I do not agree it is just a matter of style, but convention and convention becomes convention for good reasons and should be followed. Its not a religion and some time you must very from convention, but you should have a good reason. –  N4TKD Jun 19 '13 at 17:50
8  
+1 for The Codeless Code reference. This is excellent entertainment. –  Ben Jun 19 '13 at 19:36

1. Why the standard exists?

After all, wouldn't it be better to let everyone write the code according to personal preference, and stop talking about which standard is better?

The fact is that when you're habituated to one style, it is more difficult to read code which uses a different style. Your brain spends more time trying to understand the convention (if there is any), instead of understanding what the code does.

What is more readable between those two pieces of code?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

or:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Both pieces of code execute similarly. The only difference is that in the first case, each developer who worked on the project used his own style. This made the code inconsistent, unreadable and hazardous. The fact that members of the team were unable to agree about the indent size, coupled with the fact that one of them was refusing to use curly braces after every if made the code extremely error prone: looking at it, we may believe that the second if is executed only when the first if is true, which is not the case.

In the second case, all developers followed the same standard. Some of them were maybe unhappy, because they preferred two spaces indentation or because they were used to methods which start with a small letter. The fact is that the code is still much more readable this way, and still would be if they were using any different standard.

By having a strict, uniform standard, it makes the code easier to read.

2. Why their standard is better than the one I invented right now?

If a standard is used by hundreds of thousands of developers around the world, just stick with it. Don't invent your own: even if it's better, it's easier for you to migrate to the global standard rather than to those hundreds of thousands of developers to start using yours.

Example: in my own company, I have a specific convention for naming primary and foreign keys and indexes in the database. Those names look like:

  • [FK for Application: CreatedByApplicationId],
  • [IX for SessionIPAddress: SessionId] or
  • [PK for RoleOfPassword: RoleId, PasswordId].

Personally, I find this convention excellent and extremely clear. For me. But it totally sucks. It sucks, because it's mine, and because no one of thousands of database administrators never used it. This means that:

  • When I will hire a DBA, he will be forced to learn the new convention, instead of starting his work right now,

  • I can't share pieces of code on the internet as is: those strangely looking names will disrupt people who will read my code,

  • If I take code from the outside in order to use it in my own, I would be forced to modify the names in order to make it uniform,

  • If one day I decide to use some well-known standard, I will be forced to go and modify every of the few hundred names.

3. So, what about capitalization?

Properties have a larger scope or visibility than fields or local variables. Making properties start with a capital letter, and fields and variables - with a small one goes in this direction.

If you consider C#, this logic is consistent enough.

If you consider Java, methods start with small letters, which doesn't follow the logic.

So no, there is no definitive proof that this convention is better then yours. It's just that the one is used globally, and yours is not. None is better.

In JavaScript, functions start with a small letter, unless they require a new before them. Wouldn't it better the other way? Maybe. The fact is that for years, JavaScript developers used this standard, and not the opposite. Rewrite every book and force every developer to change the style now would be slightly complicated.

share|improve this answer
1  
As for the part about code being less readable because it follows a slightly different standard, I've never had that problem. Unless someone's variables are named like hookyDookyDoo, no naming or casing convention detracts from the readability. Also, do keep in mind that I am not saying my convention is "better" since it doesn't truly bring anything special to the dev table. Lastly, I don't understand your point of [Properties have a larger scope...goes in this direction]. What does the scope have to do with casing convention? Go in what direction? –  oscilatingcretin Jun 19 '13 at 17:51
19  
@oscilatingcretin, the question isn't whether you've ever had that problem, it's whether your colleagues have. Obviously they have, or they wouldn't be complaining. –  Karl Bielefeldt Jun 19 '13 at 17:58
1  
Re: your edit: Your first code example demonstrates simply poorly constructed, disaster-prone code. My OP is not about poorly constructed, disaster-prone code. It is about the exact same code as your second example, but different casing convention. I edited your second code example and posted it in my OP with my casing convention. Replace that with your first code example, please. –  oscilatingcretin Jun 19 '13 at 18:45
4  
@oscilatingcretin: The first code example demonstrates not poorly constructed code, but code written by a team where every developer followed his own style. This happens with too many codebases, given enough time (for example five years). Note: have you missed the: "The fact is that the code is still much more readable this way, and still would be if they were using any different standard."? –  MainMa Jun 19 '13 at 20:02
4  
@oscilatingcretin There's plenty of research that shows consistency significantly decreases the cognitive effort required to understand something you're reading. For regular prose, bad spelling, poor punctuation and lousy grammar all make it harder for someone to read - whether they notice it consciously or not. Code is hard enough to read, without making it harder - adherence to the "common standard" (for your technology stack of choice) increases overall consistency, and frees up neurons to concentrate on the important business of what the code does, instead of how it is written. –  Bevan Jun 19 '13 at 21:14

Technically, it doesn't matter (or at least, in most languages it doesn't).

However, most programming communities (whether those are world-wide communities that have formed around one particular language, sub-groups of such communities, groups that have formed around some popular library or toolkit, or just individual teams) have developed established coding standards. The exact details are relatively unimportant (though in many cases, a good argument can be made for them), what is important is that you stick to them.

Not because they're the best, but because they are what everyone else uses; if you stick with the standard, your code will be consistent with most of the other code that you will eventually end up using - libraries, teammates' code, language built-ins. Consistent naming is one powerful productivity weapon, because it means that when you guess the name of something, you will usually guess right. Is it file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? The naming convention will tell you.

Carrying your personal preferences into every language you encounter is particularly hazardous, because first of all, every language has its own culture, and the naming conventions are often incompatible; and second, there are many subtle differences between languages as far as naming is concerned.

Just one example: in C#, types and variables live in separate namespaces; the compiler is smart enough to know the difference. In C, however, both kinds of names share a namespace, so you can't have a type and a variable of the same name within the same scope. Because of this, C needs a naming convention that distinguishes types from variables, while C# doesn't.

share|improve this answer
    
So it really appears that some older languages have paved the road for coding standards of future languages (like your C/C# example). That is most unfortunate because having to keep track of how to case variables and object members just adds an unnecessary level of complexity that can be done without. –  oscilatingcretin Jun 19 '13 at 20:09
1  
@oscilatingcretin When everyone uses the same convention, it does not add ongoing complexity, the convention becomes part of your mental model for the language in question AND eases the use of that language. This is demonstrable and measurable. –  Mr.Mindor Jun 19 '13 at 21:36
    
I was going to vote you up but you first say that it doesn't matter then you write several paragraphs explaining why it does matter. If you delete the "it doesn't matter" at the beginning I'll vote you up. –  user61852 Jun 20 '13 at 11:32

I'm surprised no one else has said this, but I think the capitalization difference is amazingly helpful for one reason: it's nice and convenient to be able to know whether a variable is only locally scoped or not. If the variable is local than I don't worry as much about side effects of changing it, such as refactoring the name. So I like a convention that distinguishes class members versus private class variables versus local variables.

With modern Intellisense, this matters less and less, but it still gives me some landmarks as I read code to know where I should look to find the definition.

And a fair bit of this may be left over from my worse style years ago, when methods weren't as likely to fit on one screen.

share|improve this answer
    
A number of projects that I've worked on specify something like this in their style guide. –  anaximander Jun 20 '13 at 12:51

This seems more like a question of conventions rather than your specific convention.

For every convention you break, you're just adding more work for everyone else. Perhaps in a perfect world, the entire company works on a single product their entire lives... however, in reality, this is not true. People jump between projects, sometimes across companies or even for fun. The more random the code is, the harder and more expensive it is to work on. As a business owner or stakeholder, I wouldn't want to hire developers who think selfishly rather than for the good of the project.

This boils down to professionalism: sometimes we need to put our personal styles aside and go with what is more efficient for mass adoption. This encourages collaboration and removes extraneous barriers that shouldn't be there in the first place.

As for your actual convention, CapitalCamelCase is usually reserved for class names (or in Javascript, constructors). If I see a capitalized variable, an educated guess will dictate I'll need to instantiate it to use it. If that's wrong, I'm going to be pissed off that the code isn't following community standards. Even with most other languages, everybody else looking at it for the first time is instantly being misled. I want code to be obvious, not misleading.

share|improve this answer
    
"If I see a capitalized variable, an educated guess will dictate I'll need to instantiate it to use it." I do not understand. How would seeing a capitalized variable make you think you need to instantiate it before using it? Because it looks like a class name? So you don't know the difference between MyClass MyClass = null and class MyClass { }? –  oscilatingcretin Jun 19 '13 at 20:01
2  
Yes, I see the difference. The convention exists to prevent ambiguity. var car = new Car(); As per my last line - why not make it obvious? –  Adrian Schneider Jun 19 '13 at 20:40
2  
@oscilatingcretin There is a difference, of course. But the human brain benefits from visual cues that a computer parser doesn't need. It seems as if you are questioning the need for conventions/standards... which is a valid, if different question than what you originally asked. –  Andres F. Jun 19 '13 at 21:14

"because full proper case should be reserved for properties and void methods. Local variable and methods that return a value should have the first word in lowercase" and becuase it is standard convention.

Other programmers are pulling up your code right now and thinking this is a property and it is really a local variable, your making their job harder.

share|improve this answer
1  
Did you read my question in full? Take a look toward the end where I said: NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?" –  oscilatingcretin Jun 19 '13 at 17:39
6  
Yes and Yes it matters, the next programmer should never need to think NuggetCount, you should be able to look at the name and tell. A good book to read is "Clean Code" you should be able to read the code like a story and know what is happening. –  N4TKD Jun 19 '13 at 17:47
2  
@oscilatingcretin I think the frustration you are seeing with people answering slightly different questions than you are asking is evidence of the confusion that can be generated when you break accepted conventions. –  Mr.Mindor Jun 19 '13 at 20:15
5  
Conventions carry meaning. If according to convention NuggetCount implies a property, it means it has scope beyond what a local variable would have. Which means I have to research more to determine that scope. I need to determine: Are there side effects for changing it? Can I trust its value to not be changed by another thread while I am using it? nuggetCount implies local scope and I should be able to assume its whole story is local. –  Mr.Mindor Jun 19 '13 at 20:22
5  
@oscilatingcretin YES! Exactly! I trusted that what they wrote followed the convention and carried along all that goes with it. I trusted they were working as part of the team and I could reap the benefits of using that convention (knowing what nuggetCount was at a glance) If they did not, I probably do what your coworkers have done: I try to educate the one responsible, and I waste more time next time I have to follow them by not trusting. By not following the convention they have produced less readable, less maintainable code. Do you have a reason for wanting to buck the convention? –  Mr.Mindor Jun 19 '13 at 20:59

As others have said no real reason, except for getting a naming convention down pat. If you can get your whole team on the same page you can probably save yourself some time. For instance personally I started a coding standards thing which went into this and we used camelCase for all private varials as well as things passed byVal, whereas we used PascalCase for things that are public as well as things passed by Ref.

Lines get a little blurry when dealing with things like protected or Out or something.

share|improve this answer

Language (with its formal aspect and conventional) is important for organizing your thoughts, it has power over your ways of thinking. So it just a pain to transit from one style to another.

Low case and upper case symbols have big semantic differences in Haskell, also they differs lightly in Scala and I've used both of them. Other languages I use make no difference between this two kinds of identifiers, but keeping thoughts in the way Haskell perceive identifiers just much easier for me than to fragment my mind for different languages.

share|improve this answer

For me it comes down to expectation.

When I read most code, I expect anything that starts with a lowerCase to be a local variable or a function (in C# that would be just a variable). If I see a local variable in ProperCase, I would likely stumble and get confused for a while, thinking that it's either a class name or a property or something else. That would cause me to re-read the code, and would annoy me.

That is likely what's happening in your case.

Plus, it's convenient to be able to tell what role a variable plays just by looking at the first letter, and it avoids clashes between an instance name and a class name.

share|improve this answer

Lower case should be used for local variables for ease of typing (speed / no shift key). Upper case is used to help readability by separating the words within a name. Code with single-word local variable names (which should be common) are fast and easy to type. The use of upper case for each new word in the name is also faster (and less space) than using underscores which add another character - this is also known as camel-case.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.