Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

camelCase vs. under_scores #425

Closed
TrevorBurnham opened this issue Jun 10, 2010 · 17 comments
Closed

camelCase vs. under_scores #425

TrevorBurnham opened this issue Jun 10, 2010 · 17 comments

Comments

@TrevorBurnham
Copy link
Collaborator

Should the CoffeeScript convention for variable names be camelCase (as in JavaScript) or underscores (as in Ruby)? I'd like to hear some thoughts on the matter.

@collin
Copy link

collin commented Jun 10, 2010

I prefer underscores as it very clearly defines the separation between words.

That is to say: camel_case looks more like two words than camelCase.

@jashkenas
Copy link
Owner

I worried about this issue a bit while working on the compiler -- which currently uses underscore style.

If we're looking at pure readability, I don't think that there's much argument to be made for camelcase ... it's just so much harder to read as phrase than underscores are.

Unfortunately, readability isn't the only consideration -- we have to think about interoperability with javascript native functions, as well as the wealth of existing JavaScript libraries. Writing libraries in CoffeeScript that are later used from JavaScript is another concern.

I think that our real options are:

  1. Say that "under_score" is the style for CoffeeScript everywhere. If you see camelCase, you know you're dealing with a JS library.
  2. Say that "camelCase" is the style for CoffeeScript, as in JavaScript. No consistency problems, but readability suffers.
  3. Say that if you're writing a library for external consumption, please use "camelCase", but if you're writing application code, feel free to use whatever you like. Potentially the worst of both worlds.

As much as I hate to admit it, I think that option 2 might make the most sense...

@TrevorBurnham
Copy link
Collaborator Author

Actually, I must say that I find camelCase more readable. This may well be because the first language I achieved fluency in was Java (I know, ugh), so switching to a language like Ruby, my thinking is: "This is great, but why_are_these_variable_names_so_long_and_hard_to_type"? I suspect that many people who've achieved fluency in JavaScript feel the same way.

So, I favor the consistent approach. I honestly don't see any advantage to underscores. Every time I have to type an underscore, I sigh and think, "Why can't I just hold 'shift' and be done with it?" But then, I know other folks who find camelCase to be utterly hideous.

I agree that option 3 is the worst option. I think option 1 is only viable if you were to jury-rig the compiler to map parse_int to parseInt, etc. for everything built in to the JavaScript language, so that you have internal consistency.

@collin
Copy link

collin commented Jun 10, 2010

Is it too wishful to think that CoffeeScript could rewrite identifiers to camelCase.

It would make me :( to see a project like CoffeeScript go so far in making writing JavaScript nicer cave in at the end like this.

@jashkenas
Copy link
Owner

collin: Unfortunately, we can't muck with literal identifiers. Since you can access the property of an object by a string index (obj["camelCase"]), or a variable (obj[name]), it's really out of the realm of possibility...

@darwin
Copy link

darwin commented Jun 10, 2010

Let's go with camelCase (option 2). I see coffeScript more as a javascript upgrade, not as a language for ruby converts.

Readability is concern for random people looking at the code from outside. But javascript/coffescript programmers should have their brains already re-wired to read camelcase fluently. Option (1) is also pretty bad, because not everyone is going to read coding rules and it takes some time for coffeescript libraries to appear to show the right way of naming things.

@collin
Copy link

collin commented Jun 10, 2010

jashknas: Yeah, definitely a technical limitation. Sad shame of a limitation.

Well, CoffeeScript is still streets ahead of JavaScript and I agree #2 is a sensible choice given the limitation.

@StanAngeloff
Copy link
Contributor

I've had years of experimenting with conventions and my view is probably the most controversial. I would go for option #3. Why would you mind the inconsistency? Is it really that bad? I've been working with a team where we don't have a convention and everyone has to use their own style. I find it people adopt a lot faster than you would expect just by looking at a screen of someone else's code.

<jashkenas> so then, you'd go with option #3? You don't think we should even have a convention for libraries?

<StanAngeloff> yeah dont find it to be an issue

<StanAngeloff> which reminds me i wrote some coffee on top of mootools today and i didn't mind the inconsistency, even better -- made me find my code and functions faster cause they were all underscored

@weepy
Copy link

weepy commented Jun 11, 2010

I agree with Stan - there doesn't need to be a convention - just do whatever works for you are your peers. However a function is named, it doesn't offer more or less information if it's camel cased or underscored.

@ghost
Copy link

ghost commented Jun 11, 2010

App code often gets converted to lib code and vice versa, so consistency is very important here.

Consistency between CoffeeScript and JavaScript makes sense too, as CoffeeScript's code gets translated to it. E.g., using the browser's Inspector and then finding a variable/function name (in our local source files) which can be in our code and/or in other people's JS code...

So I'd definitely go for option #2.

@tcr
Copy link

tcr commented Jun 11, 2010

I would also vote for option #3. As long as a library is consistent I don't mind either style in Coffee. (For instance, I'd hate to see the source code switch to camelCase.) But for all external JS-facing interfaces (even the exposed CoffeeScript object), there's really only one choice.

My personal preference is camelCase--I don't come from a Python/Ruby background where underscores may be accepted, but while under_scores may be more legible for reading, they don't feel pretty, and I like coffee_script for the prettiness. ;) Plus, camelCase feels most natural for "web scripting", after years of JS abuse.

@tcr
Copy link

tcr commented Jun 11, 2010

@jashknas: I think this is where StanAngeloff's extension patch will hopefully inspire a culture of Coffee extensions.

For instance, authors could opt for an extension which translates all explicit property and variable references from under_scores to camelCase, provided they follow certain formatting rules (not using string indexes). Or have brackets, or use defer, or have matching JS line numbers. ;) Since coffee's just a preprocessor, I don't see why each author couldn't use their own flavor. Sounds exciting, really.

@collin
Copy link

collin commented Jun 11, 2010

@timcameronryan I like that. I understand the limitations of the identifier translation so I'm willing to take on the responsibility, but I don't want everybody to have to live in my insane fantasy world.

@jashkenas
Copy link
Owner

Alright, as of this commit, I guess that the official CoffeeScript convention is to use camelCase:

http://github.com/jashkenas/coffee-script/commit/e14f4c5db1b1b1347d3b41f4fd21348a252090fe

A sad day, but it's for the best, I'm sure.

This'll be documented for the next release. Closing the ticket.

@showell
Copy link

showell commented Jan 31, 2012

I use snake_case all the time. camelCase isJustPlainUgly.

@paulmillr
Copy link

I just wanted to say that after many months of coffee programming, choosing camelCase was a very bad idea. Code lacks readability of ruby VERY much.

@vojto
Copy link

vojto commented May 19, 2012

We're trying so hard to fix JavaScript; to make it look like Python or Ruby. Camel case is the exact opposite of that.

I'm switching back to underscore, whatever the convention is.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants