New rule request: naming conventions of methods

[gabro]

I looked for a rule for enforcing naming conventions on methods of a class but I couldn't find any.

As an example, the AirBnb style guide for React forbids prefixing methods with an underscore, but there is no way in ESLint to enforce it.

The rule I'm proposing would be an equivalent of no-underscore-dangle but for methods.

Valid examples

class Foo {
  bar() { }
}

Invalid examples

class Foo {
  _bar() { }
}

The rule has two purposes: enforcing a common style and preventing errors. The rationale behind the error prevention is that prefixing with an underscore may give a false sense of privacy, which in turn can cause mistakes, e.g. breaking changes to a method which was thought to be private.

I have already a working implementation of a more generic version of this rule https://github.com/buildo/eslint-plugin-method-names, which allows specifying a regex to which method names should confirm.

I think at least the underscore-specific version should be in the core rules, to match the no-underscore-dangle rule.

Open questions (if the proposed rule is valid):

• should the rule scope be limited at the underscore case or should it be generic and allow a regex to be specified?

  • should the rule scope include class properties defining a function? (my plugin currently does).
    E.g.

    class Foo {
      bar() { } // method, invalid
      _baz = () => {} // class property, method
    }

  would be both invalid. This is a fairly common use case when using React components, in order to bind handlers.

---

Updated proposal, after the discussion below

no-underscore-dangle will have one additional option:

• enforceInMethodNames (default: false)

---

enforceInMethodNames

Examples of correct code for this rule with the { "enforceInMethodNames": true } option:

class Foo {
  foo() {}
}

const o = {
  foo() {}
}

Examples of incorrect code for this rule with the { "enforceInMethodNames": true } option:

class Foo {
  _foo() {}
}

class Foo {
  foo_() {}
}

const o = {
  _foo() {}
}

const o = {
  foo_() {}
}

The rationale between the additional option and its default value is to make this change non-breaking.

[vitorbal]

Could this be simply an extension of the no-underscore-dangle rule instead of a new rule? We could have an option e.g. disallowForMethodNames (or allowForMethodNames with default true).

[gabro]

@vitorbal yes I think so, provided that we choose to limit this to underscores.

My current implementation is wider and allows defining a regex to test against. If that's deemed to be interesting we could have a naming-convention rule to rule them all (testing a regex against identifiers, maybe providing some default cases like dangling underscores).

[ljharb]

I definitely think no-underscore-dangle should be warning on concise object method names as well as class method names - it seems like an oversight that it doesn't already do that.

[gabro]

Concerning the possibility of extending this to arbitrary regexes, I think it wouldn't unreasonable for a team to want to enforce a convention like: no snake case for methods and variables. This would allow forbidding:

class Foo() {
  foo_bar() {}
}

as well as

const foo_bar = 42

which seems impossible with ESLint as of today.

After all, many linters of other languages support matching a regex for enforcing naming conventions.

The reason I'm bringing this up here, is that a "regex-checking" rule is introduced, it would overlap with no-underscore-dangle so this needs to be taken into account.

[platinumazure]

@gabro Have you looked at id-match? That supports a regular expression pattern but it might not enforce for method names.

[gabro]

@platinumazure totally missed it, let me check

[gabro]

@platinumazure apparently id-match checks any Identifier, so it works for class properties and methods! Thanks, I didn't know about it.

That being said, I think it's fairly difficult to use as there's no way of limiting its scope to methods.

Also, it already overlaps with no-underscore-dangle.

So my proposal would be to extend no-underscore-dangle to include methods and class properties (configurable) and leave id-match to handle all the other cases.

Does it sound reasonable?

[platinumazure]

@gabro To be honest, I would prefer extending id-match to support different patterns for different types of identifiers. But let's see what others think.

Long term, it would be great to deprecate and remove no-underscore-dangle since it's basically covered by id-match, but I don't think that's going to get a lot of traction with the team.