A standard for usage of snake case, camel case, pascal case etc?

[ilearnio]

For example, I'm using snake case for variables and object properties, camel case for functions/methods and pascal case for classes. And it is really sad when someone else starts to use a different approach in the same project.

A rule for which case type to use when defining of variables, functions and methods etc would be highly appreciated!

Thanks!

[LinusU]

Virtually every javascript I've seen uses camelCase for both variable and function names, and PascalCase for class names. Constants are usually written with ALL_CAPS. I would love seeing this enforced in standard.

It's important that it only checks when declaring new variables though. Also, it should allow leading _ since that is by convention the way we use to mark variables as private.

There is an eslint rule for this here: http://eslint.org/docs/rules/camelcase

Would be very interesting to run the test on all repos with this enabled :)

[notslang]

👍 for enforcing camelCase on vars/functions, PascalCase on classes, and ALL_CAPS on constants. Given that the functions that are built into JS use that naming style, I think it's reasonable to add it to standard.

[grantcarthew]

I disagree with using all caps with const variables. As do the developers working on Node by the looks of it. I am using const in my node modules when requiring modules. All caps would look very messy.

[sotojuan]

I also dislike all caps for constants, but sadly everyone in the React/Redux community uses them for actions, so it'd break a lot of stuff. Of course, this is supposed to be an opinionated project so ultimately it's up to @feross.

[ilearnio]

I am using const instead of var and let everywhere in my code where it's possible, to make it more readable. It's much easier to reason about code when it is dead obvious what can change and what cannot change. I am using ALL_CAPS only for global constants, and snake_case for local ones

[feross]

@LinusU I agree with you, would like to see what breakage this would cause in the ecosystem before considering it.

[simonratner]

I am with @grantcarthew and @ilearnio; const is used for a lot of things besides the traditional "variable holding a constant literal". It would be pretty arbitrary to enforce a different name just because one chooses to make a value immutable.

[feross]

@simonratner Yes, this is a good point. I don't think we can ever assume that all const variables are the top-of-the-file or global constant kind.

But enforcing camel-case instead of snake case is more likely to work, i.e. not cause a bunch of test failures :)

[feross]

Camel case variables are now enforced in standard 7.0.0-beta.0.

[bganicky]

Any suggestion how to solve scenario where I have keys in a dataset from an API (I can't modify it) and want to use object destructuring assignment?
let { route_id, std_date, std_time } = flight
This of course results in a "Identifier 'std_date' is not in camel case" Standard error. Just use standard variable assignment instead?

[feross]

I suppose this would work:

let { route_id: routeId, std_date: stdDate, std_time: stdTime } = flight

[bganicky]

So obvious. Thanks! :)

[mderazon]

This breaks my heart 💔

Aesthetically I prefer snake_case but i'm willing to change it to comply with Standard.

Problem is that our api keys are 100% snake_case and also keys stored in our db (Mongo). I know that camel case is not enforced on props, but I don't want code that's half camel half snake or worry about translating between them all the time like @feross suggested above.

I understand the decision though. Maybe on a new project I will do stuff differently, but for my current one I guess it's back to ESLint

[sorahn]

@mderazon use eslint with eslint-config-standard then just override the rule for camelcase.

[feross]

@mderazon Yeah, I respect your decision to use eslint directly. standard has the goal of reducing ambiguity so that we can all give less feedback in PRs, so I think standardizing on camel case is a net win, even if it makes it a bit more annoying to interact with APIs that use snake_case. It helps that there's no enforcement on property names.

[billiegoose]

I wanted to complain bitterly because I had a project that used standard and was fine, and then I came back to it after months and now it's telling me to use camelCase and I thought... "Really? I have to rename ALL my variables? Functions and methods use camelCase, but surely people use snake_case for local variables..." and then I look around (literally, I just looked through a bunch of files in express, babel, and even coffee-script) and couldn't find any snake_case.

"But I used snake_case?! Where on earth did I learn that?" I wondered. Then it hit me: python. I quickly googled "python tutorial" and the first one that pops up used snake_case:

>>> the_world_is_flat = True
>>> if the_world_is_flat:
...     print("Be careful not to fall off!")
...
Be careful not to fall **off!**

"I'm not crazy!" I thought. "I came to JavaScript from CoffeeScript; I bet I carried that over from Python!" I rushed to the CoffeeScript website to confirm, but no! The CoffeeScript docs used camelCase. "Am I going crazy?" I thought. "Where the heck did I pick up this convention?" But finally, I went to the CoffeeScript Cookbook site, and found a good many of the code snippets there used snake_case... inconsistently.

TL;DR And that's the story of how I realized I've been naming variables weird for a long time. A tale of anger, curiosity, confusion, panic, soul-searching, and (finally) self-understanding.

[feross]

@wmhilton Heh, thanks for sharing your story ;-)