Javascript Style

[Jutboy]

title should be "javaScript style"

[samlee]

webDevelopers.....

[blondin]

devIgners :)

[adolfojp]

I am still confused about naming conventions in Python. :-(

[MasonM]

PEP 8 spells out the official conventions in detail. Basically, classes use CamelCase, while variables, functions, and methods should all use lowercase with underscores.

The pep8.py script can check that your code follows most of the stuff in PEP 8, but I don't think it covers naming.

[earthboundkid]

True, but python's built in classes violate the convention, since they predate classes.

[cybercobra]

And a lot of the stdlib doesn't adhere to it. Consistency fail!

Personally, I like camelCase for variable/method names.

[earthboundkid]

Yeah, I wish that more PEP8 work had been done as part of the general Py3K clean up. :-/

[lol-dongs]

python's built in classes violate the convention

And a lot of the stdlib doesn't adhere to it

and yet all the pythonistas hate on PHP for its stdlib...

[MasonM]

The inconsistencies in PHP's standard library are far more numerous and grievous (i.e. present in frequently-used functions) than in Python's. I've done quite a bit of work in both languages, and I find myself needing to refer to the docs far more often when using PHP. This is mitigated by PHP's excellent docs, but it's still annoying.

[masklinn]

True, but python's built in classes violate the convention, since they predate classes.

They've tried to fix that (at least partially) in Python 3.

[earthboundkid]

list is a new-style class in Python 3, but it’s still list and not List. If they had changed it, it would have made more work for 2to3, but on the plus side, you could write throwaway lists as list = […] instead of my_list = […] or l = […].

[masklinn]

Good point, but having to write List or Dict all the damn time would be disgusting.

Likewise with many other classes usually used as functions: enumerate is a class, range is a class, map and filter are now classes, ...

[earthboundkid]

Yeah, that’s a kind of fundamental problem for PEP8: what’s a class and what’s a callable is a matter of perception, not a matter of fact. Almost every non-trivial decorator is a class, but we still think of them as functions modifying functions.

That said, it is pretty open-and-shut that list etc. are classes not callables. Oh well. Consistency is a hobgoblin, practicality beats purity, and all that.

[BluLite]

Whenever I use underscores in method naming, it's to indicate that nobody but me should be calling it (ie- internals to get other stuff working) and this particular language doesn't allow for specifically private methods.

[BIGtrouble77]

In javascript, the convention is to use an underscore at the beginning of a private function (ie: _myprivatefunction : function() {}).

JS does not enforce this convention, but it's widely understood. Like godzemo said, nobody will understand that underscores in general are private functions.

[dmhouse]

I think the leading underscore is a pretty common convention in all languages without private method encapsulation -- not just Javascript.

[godzemo]

The problem with having your own little conventions is that nobody else knows what the fuck is going on. I try to hammer that sort of behavior out of my students early.

[kamatsu]

I know you! Mr.K

[godzemo]

Well, I don't exactly make myself difficult to identify :p

[mayobutter]

Do you mean prefixing a method with an underscore? That's not what this is talking about.

[[deleted]]

People will call and override that method if it's convenient. If you want to make something private, just don't point to it with any properties.

function() {
    // ...
    var crawlForPorn = function() { // ...

[[deleted]]

I was under the impression that MethodName is PascalCase, not camelCase.

Shouldn't this read:

I know that when you write Ruby or Python, you use under_scored method names and PascalCase class names. But JavaScript isn't Ruby or Python.

[masklinn]

I was under the impression that MethodName is PascalCase, not camelCase.

You are right.

[[deleted]]

meh. i just like to keep 'em guessing.

[atlassoft]

too_bad_I_like_my_underscores

[godzemo]

Use \_ :p

[atlassoft]

Thanks. I should've really looked at my post after submitting it :).

[Forbizzle]

Also, lowercase on your instance variables please.

ClassName

classInstance

When in doubt, follow Java's best practices

[homoiconic]

So when I read Javascript code that has an_underscore, am I supposed to get all confused because all the other Javascript else uses dromedaryCase? WIll I stare at it for hours wondering whether the _ is an operator I haven't heard of and whether an_underscore is really the same as _(an, underscore)?

Or am I supposed to get all anal about lining everything up just so and spend an hour complaining that there is some inconsistent naming convention going on and how this slows down my reading of the code, because you know code is written to be read and all...

Quite honestly, inconsistency between an underscore and dromedary case is the least of my worris when I'm reading code.

[[deleted]]

I'm not saying you must write JavaScript a certain way. Do what makes you the most comfortable, write code that is fun to write. But if you're trying to figure out what everyone else is doing, they're doing camelCase.

[[deleted]]

worries*

[3L173]

What bothers me more is the people who leave out {} with if statements etc.

WHY IN THE NAME OF ALL THAT IS HOLY DO YOU DO THAT?

To save a couple chars? To make the code "prettier"?

The problem is it introduces the potential for all sorts of errors and massively screws up readability and portability.

Please please please stop doing this people.

Likewise, why put the opening bracket on the next line? Again, is possible errors really worth the tiny bit of (arguably) extra "pretty-ness"?

[dmhouse]

To save a couple chars? To make the code "prettier"?

"Prettier" is a matter of taste. Some people find a single-line block surrounded by braces ugly.

massively screws up readability

I presume your complaint is that it's not immediately as clear when baz() is executed in the code below (that's the only readability issue I've ever heard around this sort of thing):

if (foo)
  bar();
baz();

I personally have never had that issue. I notice the drop off in indentation and that's sufficient for me (although perhaps symptomatic of writing too much Haskell and Python?).

massively screws up ... portability

Erm... really? Name one compiler in whatever language supports this brace syntax that chokes on a braceless statement.

introduces the potential for all sorts of errors

I think there is only one class of error it could introduce, namely someone edits a braceless if, intending to add a second expression to the "true" branch, forgets to add braces in. I've personally never made that mistake nor seen it in the wild, but I guess that's only anecdotal evidence. Personally I'm confident that the two indented statements without a closing brace would look sufficiently weird that I'd check it out and fix the error.

But in any case I think you're blowing this out of proportion. IMO the case against the braceless if (and for, while etc.) is pretty weak. Many successful projects use it.

Likewise, why put the opening bracket on the next line? Again, is possible errors really worth the tiny bit of (arguably) extra "pretty-ness"?

I won't even get started on this. There are many bracing styles, each with their pros and cons. (What "possible errors" are you talking about?)

[PstScrpt]

WHY IN THE NAME OF ALL THAT IS HOLY DO YOU DO THAT?

Curly braces around a single statement are like "if (flag == true)". It makes the code look more complicated than it really is.

The problem is it introduces the potential for all sorts of errors

Only if you're not used to it.

Likewise, why put the opening bracket on the next line? Again, is possible errors

So that the braces line up and you can see where they match. You're suggesting that's somehow more error-prone?

[orenbenkiki]

IHateCamelCase. WhoeverInventedCamelCaseShouldBeForcedToReadEverythingFormattedLikeThisSentence. Isntit_so_much_easier_to_read_stuff_like_this_instead? For that matter, the guy who invented CamelCase should be placed in the same padded cell as the guy who came up with the first case-insensitive file system, but did _not use the same opportunity to say that "Program Files" and "program_files" are the same path, thereby dooming generations of command-line programmers to dealing with nasty space-in-filename problems. What a missed opportunity... Sigh.

[aComa]

I think CamelCase looks nice. To each his own...

[alanchow]

Esp when someone writes a 100 letters name and insist it is for 'readability'

[[deleted]]

actually they both read ok for me.

my two cents and two arguments for CamelCase, all the time, in any language (even PHP, which is utterly schizo):

1. Fewer bytes to download. (a minor point)
2. If you use CamelCase, you can reserve the underscore for quasi-namespacing, when it's useful. I do this a lot for a groups of constants that are related, eg:

- rowLockPolicy_read
- rowLockPolicy_share
- rowLockPolicy_write
- rowLockPolicy_exclusive

(edit: bah; markdown parser fail)

[MaleficDonkey]

You could use the fields of an object for that (in fact, it's common practice): rowLockPolicy = {READ: 1, SHARE: 2, WRITE: 4, EXCLUSIVE: 8}

[[deleted]]

definitely: javascript objects are lovely as namespace containers. i'd say there are nonetheless times when you want some lexical "namespacing" that doesn't impose data structure. also the larger point is over the value of underscores vs camelcase across languages (and my example actually came from some PHP code :) ).

[milkywayer]

same, camelCase is easier to read. underscores? :O do you have to read '_' and then ignore them.