JS style guide: does the camelCase naming convention apply to object properties?

[mikesherov]

Should either of these be violations:

a.snake_case

{
   snake_case: a
}

[scottgonzalez]

They seem like they should both be violations. What is the scenario where this exists?

[mgol]

IMO the latter should be a violation, the first one shouldn't (unless it's 'a.snake_case = sth'). This boils down to the fact the rule should check only assignments and not reads; the latter may come from external APIs we don't have control over so it's silly to enforce anything there.

On Thursday, June 5, 2014, Mike Sherov notifications@github.com wrote:

Should either of these be violations:

a.snake_case

{ snake_case: a }

— Reply to this email directly or view it on GitHub https://github.com/jquery/contribute.jquery.org/issues/81.

Michał Gołębiowski

[mgol]

OTH, sometimes an API might require an object with snake_cased keys as well so the problem might be not so narrow...

Anyway, if this is an variable/property name of an object we have control over we define it somewhere so an error there is enough, no need to repeat it. And reads from external APIs are usually more common than writes so restricting it to writes should limit the number of cases where one needs to bypass the rule.

[mikesherov]

@scottgonzalez they exist in the gruntFile configs. The reason I ask is that it's easy to alias other variable names: var conforms = doesnt_conform;

It's harder to start reassigning property names in a way that causes no breakage.

[mikesherov]

My preference would be that only variable names are enforced, but I'll make it configurable.

[mikesherov]

so I'll include options for object define { a: b} vs. object access/assign a.b or a.b = whatever.

[scottgonzalez]

I don't think it's possible to have an automated check that handles this properly without inline flags. If you want to do automated checks on variable names but not property names, that seems fine.

[mikesherov]

Right, we'll employ inline flags at some point. I'm trying to model the jQuery style guide in a way that makes it easy for people to use regardless of an automated checker or not.

[mikesherov]

Closing this. Seems like we're going to use the "inline ignore" strategy for any automated tool, but keep this as part of our style guide to avoid ambiguity. Thanks for the discussion!