Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

rule extension: camelcase ignore prefix/suffix/patterns before validating

See original GitHub issue

I’d like to provide optional settings that relax the constraints on camelcase to support the use of non-conforming identifiers in cases where style requires them.

The driver for me is projects where variables and properties that hold physical measurements must indicate the units of measure in a suffix with an underscore separator. For example ambientTemperature_cCel or centerFrequency_kHz should be allowed as properties or variables. When this was discussed prior to acceptance in JSCS other use cases were NPM script config values (process.env.npm_package_config_MY_ENVIRONMENT_VARIABLE) and the Google style for optional parameters opt_varName and var_args.

My proposal is to extend the camelcase object option with three properties, the value of each of which is each is an array of String or ESTree RegExpLiteral objects:

  • allowedPrefixes identifies text which, if it appears at the start of an identifier, is stripped off before checking the rest of the identifier against the camelcase expectations;
  • allowedSuffixes does the same for text that appears at the end of the identifier;
  • exceptions are full identifiers or patterns where violations of camelcase are ignored

For example, the Google style options could be supported by:

  • "allowedPrefixes": [{"regex": {"pattern": "^opt_"}}]
  • "allowedPrefixes": [{"regex": {"pattern": "opt_"}}]
  • "allowedPrefixes": ["opt_"]
  • "exceptions": ["var_args"]

An example to support identifiers holding frequency measurements with various multipliers would be:

  • "allowedSuffixes": [{"regex": {"pattern": "_[kMG]?Hz"}}]

which would allow baseBand_MHz, channelStep_kHz, offset_Hz and others.

Before I proceed with this, are there strong feelings against adding this feature, or an alternative interface that would be preferred?

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Comments:14 (8 by maintainers)

github_iconTop GitHub Comments

pabigotcommented, Jun 23, 2016

@aubergine10 Thanks for raising that. I mis-wrote the example regex to include an anchor that should not have been there. I’ve corrected the original description.

One reason is to make the three cases consistent: all three take strings or regexps. For example I might want a suffix string _Cel and a suffix regexp _[kMG]?Hz. In both cases the fact it’s a suffix is more relevant than that it’s expressed as a string or regexp, and this is indicated by putting it in the allowedSuffixes property. The regex is simplified by skipping the explicit anchor: a match is recognized when it occurs at the start (prefix) or end (suffix) of the identifier.

A key point for prefix and suffix is that whatever doesn’t match the identified affix remains subject to the original test. For example with a suffix exclusion _Cel I’d want insideTemp_Cel to be allowed but outside_temp_Cel to produce a diagnostic.

If the difference between prefix and suffix were removed for regex affixes in favor of explicit anchors with something like:

allowedAffixes: [{regex: {pattern: '^opt_'}}, {regex: {pattern: 'req_'}}]

the absence of an anchor in the second “affix” results in confusion: foo_req_bar matches internally, so what part of the other pieces must be checked against the camelcase requirements? (Using capture groups just becomes ugly really quickly.)

With exceptions the interpretation is different: if the identifier as a whole is (exactly) the string or matches (anywhere) the regex, it’s passed without further checking of any sub-identifier. In that case the anchors would need to be explicit to be relevant: for example using this to accept any identifier that begins with ignore regardless of case and presence of underscores:

exceptions: [{regex: {pattern: "^ignore", flags: "i"}}]
kryten87commented, Dec 16, 2016

I’d like to see an exceptions argument on the camelcase rule. I have legacy code which is pulling data from a database in which the column names contain underscores. I’d like to be able to implement this on a per-module basis.

For example, I have a module with code that works with customer objects containing fields like first_name, last_name - I’d like to make exceptions for those fields, while still flagging any other instances of variable names that violate the rule.

Ideally, I’d like to refactor the database & the legacy code to remove these underscores, but that’s not practical.

Read more comments on GitHub >

github_iconTop Results From Across the Web

naming-convention | typescript-eslint
camelCase - standard camelCase format - no underscores are allowed between characters, and consecutive capitals are allowed (i.e. both myID and myId are...
Read more >
Disable check of camel case rule in eslint - Stack Overflow
I am trying to disable them and address them one at a time. The code below shows that I can disable them all...
Read more >
Chapter 5. The Rule Language -
A rule file is typically a file with a .drl extension. ... For backwards compatibility reasons it's allowed to suffix patterns with the...
Read more >
Naming conventions for records | Pega
For records that derive from Rule-File- class, select a name that uses only lowercase characters to avoid confusion between systems which have ...
Read more >
Using Templates - OpenAPI Generator
NOTE: Some generators may be sensitive to which files exist. If you're concerned with redundant files like pom.mustache and build.sbt.mustache , ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found