Require function names to match the name of the variable or property to which they are assigned

[feross]

This rule requires function names to match the name of the variable or property to which they are assigned.

http://eslint.org/docs/rules/func-name-matching

[mightyiam]

I can see how this can prevent hair-loss in debugging.

[timoxley]

Bitten by this. "How the shit is that function even being called, that's not even the right line number..." then going off trying to figure out what's wrong with my source maps... only to notice later they were just fine, the bug was something else entirely and I had just wasted an hour because I'd copy/pasted a function signature but forgot to rename it later. +1.

[dougwilson]

This change seem cool to me. I try to keep the function names matching the method name when assigning to the prototype (old school, I know), but it's easy to make mistakes.

[jprichardson]

On the surface this one seems great... but will it screw with monkey patching? What about bind? If so, are there viable work arounds or recommended alternatives?

e.g.

let oldLog = console.log
console.log = function (msg) {
  console.log('patched!')
  oldLog(msg)
}

Will that work? or will I have to name it let log?

Also, what about using bind? That changes the function name IRC.

[dougwilson]

Your example and .bind work just fine what that eslint rule and are allowed, afaik.

[Flet]

For fun, ran this rule against the standard-packages set used in tests.

func-name-matching	% Pass
["error"]	94.2% (310/329 repos)
["error", { "includeCommonJSModuleExports": true }]	79.9% (263/329 repos)

[yoshuawuyts]

I think I'm 👎 on this change, this is problematic for the following case:

module.exports = function () {
  return {
    class: createClass,
  }
}

// 'class' is a reserved word, so thus cannot be used
// as a function name
function createClass () {
}

This would force authors to either:

1. adopt ES6 and use the { [class]: createClass } syntax
2. change their API, forcing semver major

Both of which are not necessarily an option - the only option would then be to disable it in specific locations.

I'd be fine with this rule being enabled if it solved a problem, but to my knowledge I've never run into this before so I don't feel the costs outweigh the gains.

Also in the case of ["error", { "includeCommonJSModuleExports": true }] it actually makes stack traces worse as functions are no longer named - and we can no longer hoist functions for the common pattern of:

const foo = require('bar')

module.exports = mainView

// description of what it does
function mainView () {
}

Thoughts?

[Flet]

Both of those cases pass this rule without issue @yoshuawuyts 👍

This does not pass:

var foo = require('bar')
module.exports.foo = function mainView () {}

Strangely, this one also passes just fine:

var foo = require('bar')
module.exports.foo = mainView
function mainView () {}

[Flet]

...and for good measure... this also fails:

module.exports = function () {
  return {
    class: function createClass () {}
  }
}

[dcousens]

ACK

[caesarsol]

Yeah, the rule works only on functions defined inline on an object property or property reassign.

Is this going to completely forbid anonymous functions as object property? Because I'd love it for debugging :)

👍

[feross]

Moderate impact on ecosystem (~5%). Not automatically fixable.

# tests 287
# pass  273
# fail  14

There also seem to be some cases that are forbidden but that seem reasonable to me:

Case 1: exposing a method with a short name like require('get-installed-path').sync, but giving it a more descriptive function name:

module.exports.sync = function getInstalledPathSync (name, opts) {

module.exports.sync = function isInstalledSync (name) {

round.down = function roundDown (value, multiple) {

exports.es3 = function fillKeysEs3 (destination, source) {

Scale.create = function Scale$create (prefixesList, base, initExp) {

Case 2: setting function as a generic property name like command, required by certain APIs, but giving the function a more descriptive name:

{
  command: function cat (args) {

Case 3: naming a function differently to prevent shadowing:

function humanizer (passedOptions) {
  var result = function humanizer (ms, humanizerOptions) {
    var options = extend({}, result, humanizerOptions || {})
    return doHumanization(ms, options)
  }

There are enough legit cases that I'm hesitant to include this in v10. If anyone who argued for this rule disagrees, feel free to continue discussion below. I'll close this for now.