What is the best-practice casing style for javascript? Why?

Question

One aspect of javascript that it's hard to find information on is casing practices. By casing practices, I mean what casing style (ie. camel-case, pascal-case, etc) should be used for what elements (Constructors, private functions, public functions).

The only rule I've heard was from a Douglas Crockford lecture on YUI theater, stating that constructors should be the only functions that start with an uppercase letter.

Beyond that there doesn't seem to be many casing standards that people follow in javascript.

Does anyone know any casing best practices for javascript, and why it's reasonable to use them?

Also do you follow a casing style with your .js files?

Answer 1

I prefer PascalCase for constructors and camelCase for everything else. That's the style that JS standard library uses and well... every JS framework I've seen so far :)

And I use all_lowercase naming convention for all files served from web. There are some case-insensitive file systems out there.

Answer 2

+1 for PascalCase for constructors and camelCase for others. As for filenames, I use underscores.

Answer 3

I prefer camelCase for everything except for constructors. The reason (and I believe this is why Mr. Crockford suggested this as well) is because in other languages, such as Java, the convention is capitalize your classes, which is what constructors are used for.

That is my $0.02.

Answer 4

The core language uses InitialCaps for constructors (e.g. Object, Date, Number, RegExp) and camelCase for methods and properties (e.g. something.toString(), quantity.valueOf(), regexp.ignoreCase). This convention is also followed in the DOM specifications and implementations (e.g. HTMLElement.setAttribute()). So it makes the most sense to adopt the same convention, or you finish up with a horrendous mishmash of styles like:

var number_of_fish_requested = document.getElementById("fish").value;
var fish_count = parseInt(number_of_fish_requested, 10);

which just becomes utterly confusing, not only to type but, much more importantly, to read.

(You spend more time reading code, trying to debug or modify it, than you ever do writing it in the first place.)

Answer 5

All lower case with underscore separators is the easiest to read; it follows natural language. "Best" will get you in to a holy war; the reality is case doesn't matter as much as other design issues but it's an easy topic to polarize.

ALongButNotReallyReadableIdentifier
an_even_longer_but_completely_readable_identifier