camelcase

[eliasmalik]

http://eslint.org/docs/rules/camelcase

camelcase: "error"

Prefer consistent naming convention, camel case is more idiomatic of javascript.

[SimonLab]

I prefer using camelCase but this one is tricky, a lot of people prefer using other styles for naming variables and functions. I agree we need consistency but I'm not sure if camelcase is the right one to choose.

[nelsonic]

@eliasCodes I agree that camelCase is "idiomatic" in JS for method names. 👍
I prefer snake_case to camelCase but I don't have a "valid" reason other than letting the words "breathe"...
(AFAIK) There isn't anything in "The Good Parts" that dictates variable naming convention.
And we already use ALL_CAPS_SEPARATED_BY_UNDERSCORES for environment variables
see: https://github.com/dwyl/learn-environment-variables#environment-variable-naming-convention
Which I think makes things really clear.

What I'm tempted to say is:

• method/function names should be camelCase
• property/variable names should be snake_case

I think this would be reasonably beginner friendly ... thoughts?
This is the subject of many "flame wars", e.g: https://news.ycombinator.com/item?id=6777750

possibly related to: dwyl/abase#24 and dwyl/abase#26

[cristinecula]

Will you be mostly using hapi as the framework?
If that's the case you should probably adhere to the hapi style guide:
http://hapijs.com/styleguide#variable-declarations

Use camelCase, never underscores

[eliasmalik]

@nelsonic having a quick look at the rule specification, I can't see a way to implement that split between methods/functions and properties/variables. This would require us to write a new rule. I don't have a particularly strong opinion, and can see how your suggestion would make it clear what names hold values and which hold functions.

@cristinecula We do use hapi, although I don't think we feel bound by their style-guide. For example, hapi's styleguide recommends using const and let over var, whereas we do the opposite for various reasons (see #13 and #10), as well as it being recommended in The Good Parts

[nelsonic]

@cristinecula that's a really good question! (and something that requires clarification)
Yes, we are using hapi because we think it's the most well-tested and simplest HTTP framework in Node.js-land. see: https://github.com/dwyl/learn-hapi#why-hapi-instead-of-xyz-framework

However using hapi does not mean we have to follow hapi style guide.
(to be clear we actually like most of the "rules" in the Hapi style-guide and we are stoked that the Hapi team have a good standard, but they are very server-focussed and not generally applicable to all JS code...)

for example: Variable Declarations http://hapijs.com/styleguide#variable-declarations

Sure, we can use const and let on a node.js (hapi) server, but the objective of this repo is to give people a lint config they can use to write code that "_Works Everywhere^TM_"
(i.e. we don't plan on using goodparts only for hapi projects...).

see:

• let: let or var? #10
• const: const #13

[nelsonic]

@eliasCodes did you see http://eslint.org/docs/rules/camelcase#never ?
again, I would make the case for encourage this because it makes the distinction between methods and properties immediately obvious.
More this:

Less this:

For now I would suggest that we keep this rule set to:

camelcase: ["error", {properties: "never"}]

To me this makes our code more beginner-friendly ... but as always I'm all ears for a different perspective.

[eliasmalik]

@nelsonic doesn't that still force you to write variables in camel case? i.e. it would make

var myCamelCaseVar = 1;

valid but

var my_snake_case_var = 1;

invalid. This is still one step closer to what you want, but not exactly it. But happy to change to your suggestion if you're happy with this.

[nelsonic]

busy updating existing code to use goodparts
really not a fan of being forced to use camelCase ... 😞
don't see what value it adds ... understand that "consistency" is good... but this is painful.
But in the interest of avoiding a (non/conformist) flame war https://news.ycombinator.com/item?id=6777600 ...

[eliasmalik]

@nelsonic with stylistic rules, I don't have particularly strong feelings. Happy to change to "off" if you'd like (and if no one else objects).

[nelsonic]

@eliasCodes if no-one else objects, I would be grateful if this was turned off ... not "urgent" tho.
(I've changed all the snake_case in the code I'm busy with to camelCase in the short-term ...)

[SimonLab]

ok let's give a try to snake case, @nelsonic do you use snake case for everything (function name, variables, properties)?

[nelsonic]

@SimonLab good question. I want to make the case snake_case for variables and Object properties ... but in the past, yes I have used snake_case for functions too ... but I would never force that on anyone else. and I would rather have something consistent that I personally didn't like than a personal preference that opened the floodgates to inconsistency... 🤔

[iteles]

A note on this here: https://github.com/dwyl/style-guide#variable-naming

[nelsonic]

These guys did the Science: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf or ICPC2010-camelCase-vs-underscore.pdf

have you found any other empirical studies that support camelCase as being "faster to read"...? (not the dogmatic "that's how JS language features are implemented so we should follow the leader...")