Javascript: Question about object naming conventions

Created on 25 Feb 2017  路  5Comments  路  Source: airbnb/javascript

22.2 and 22.8 seem to contradict each other

22.2 says use camelCase for naming objects
22.8 says use PascalCase when exporting a bare object

Is it intended that an object should be named using camelCase, but exported under a different, PascalCase, namespace?
Also, when importing, if using the same name as the default export, we would have an object that is PascalCase.

It seems it would make the most sense for the thing being exported to dictate the export name.

Most helpful comment

Certainly importing an object should import it as PascalCase, and the filename it's imported from should be PascalCase as well.

22.8 modifies 22.2 by saying that when you export the object, it has special rules - just like when you new a function, it should use PascalCase even though functions should normally be camelCase. I don't think 22.2 and 22.8 contradict each other.

All 5 comments

Certainly importing an object should import it as PascalCase, and the filename it's imported from should be PascalCase as well.

22.8 modifies 22.2 by saying that when you export the object, it has special rules - just like when you new a function, it should use PascalCase even though functions should normally be camelCase. I don't think 22.2 and 22.8 contradict each other.

@ljharb Does it correct? Should it rather be errorCodes.js or error-codes.js?

// ErrorCodes.js

export const BAD_PASSWORD=1;
export const NOT_FOUNT=2;
etc...

@rosendi certainly not ErrorCodes because it's not a constructor or a namespace; and not error-codes.js because we camelCase our filenames - so I'd go with errorCodes.js, or errorCodes/constants.js.

22.8 modifies 22.2 by saying that when you export the object, it has special rules - just like when you new a function, it should use PascalCase even though functions should normally be camelCase. I don't think 22.2 and 22.8 contradict each other.

@ljharb Why are objects an exception when getting imported, while others like functions, classes etc. keep the same casing locally and when imported? I find this brings a lot of confusion. Functions can be easily distinguished from objects by using verbs instead of nouns, so even if they both use camelCase it should still be clear which is which. However, object instances and classes use the same casing when imported, which would in example mean that a Car class and a car instance are both imported as Car.

So, three problems there:

  1. It makes it impossible to distinguish an object from a class/constructor.
  2. Objects are camelCased on export but PascalCased on import, which means that we also need to change their names when destructuring them. Example:
    // bad import { someObject } from 'someLib'; // good import { someObject: SomeObject } from 'someLib';
  3. Regarding using two different types of casing... Why make objects an exception in the first place, when all other types of data are consistent in being independent of being local/external?

In general, exporting an object is an antipattern anyways.

The "exception" is because "what it is" isn't defined by its JS type - iow, an object - it's defined by its conceptual usage. When used as a namespace, it has a specific semantic meaning, and thus its capitalization follows suit.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

golopot picture golopot  路  3Comments

xgqfrms-GitHub picture xgqfrms-GitHub  路  3Comments

danielfttorres picture danielfttorres  路  3Comments

tpiros picture tpiros  路  3Comments

zurfyx picture zurfyx  路  3Comments