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.

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

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.

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.

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.

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.

“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.

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.

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.

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.

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.

I agree with the OP here. camelCase just looks wrong. I also agree with the fact that that is the standard and we must stick to the same standard or what is the point of having a standard. It also makes sense that PascalCaps be used for methods etc and camelCase for your own variables etc as a way of differentiating when not using an IDE that colors methods for you.

To get around it, I always prefix my object’s names with the type of object it is. So if it is a string variable I call strMyVariable. If it is some sort of object I call it objMyObject, etc. That way it starts with small caps as per the standard and it looks right.