Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rule proposal: no-improper-camelcase #427

Open
robatwilliams opened this issue Oct 29, 2019 · 3 comments
Open

Rule proposal: no-improper-camelcase #427

robatwilliams opened this issue Oct 29, 2019 · 3 comments

Comments

@robatwilliams
Copy link

robatwilliams commented Oct 29, 2019

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Collaborator

fisker commented Oct 30, 2019

How about make a dictionary, and use

const words = name.split(/(?=[^a-z])|(?<=[^a-zA-Z])/).filter(Boolean);
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

@sindresorhus sindresorhus changed the title Rule proposal: no-improper-camelcase Rule proposal: no-improper-camelcase Jan 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants