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

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?

[pabigot]

@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"}}]

[kryten87]

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.