Rule proposal: `no-improper-camelcase`

[robatwilliams]

This rule would fail when the constituent part of closed-form compound words are capitalised.

Fail

function unSubscribe() {}
let passWord;
let isInViewPort;

Pass

function unsubscribe() {}
let password;
let isInViewport;

Problem statement

Compound words are formed by joining together two or more other words. Closed-form compound words do that without a hyphen/space. They are words in their own right, and should be treated as such when applying programming casing conventions.

Time and again I see these words incorrectly treated as separate words for the purpose of camelCase. This causes the following problems:

• confusion and bugs when code using one form interacts with code using the other form
• spread of incorrect form throughout codebase in the name of consistency
• personal aggrevation

Examples

Standalone: callBack, dataBase, fileName, lookUp, offLine, onLine, overRide, passWord, payLoad, placeHolder, preView, setUp, unSubscribe, userName, viewPort, weekEnd

Combined: isInViewPort, showPreView, isOnLine

Some of these are arguably OK, others are definitely not.

Existing solutions

The ESLint rule id-blacklist can be configured to disallow a list of identifiers. It has some limitations (by design) which make it less than ideal for this problem:

1. Only works on complete names, i.e. would not detect isInViewPort
2. ESLint rule options configured in a shareable config cannot be extended/merged by an extending config; the entire options object must be copied into the extending config.

[sindresorhus]

I haven't really seen this problem myself, but it makes sense as a rule.

How do you plan to gather the words? Do you have a source in mind or is it going to be a manually made list?

I think we could reuse a lot of the machinery for the prevent-abbreviations rule for this.

[robatwilliams]

I think it's more common when developers with less good English are (or previously were) working on a project.

A clever approach for the word list might analyse a Hunspell dictionary to identify compound words, either at plugin build-time or at runtime. I'm not convinced that effort would be justified, so a manual list of words that come up in development would be simpler and sufficient.

[fisker]

How about make a dictionary, and use https://github.com/sindresorhus/eslint-plugin-unicorn/blob/f79cd8389398926757c6f7321e95e622ad92dd88/rules/prevent-abbreviations.js#L277 to spit words and check all combinations except words

say we have password in dictionary

passWordPress, split into [pass, word, press] , check ~pass~ , password, passwordpress, ~word~, wordpress, ~press~

this passWordpress, split into [pass, wordpress] will not fail, check ~pass~ , passwordpress, ~wordpress~