Rule Proposal: newline-in-function-parens

[mysticatea]

EDIT: I updated options in #6074 (comment)

---

From validateAlignedFunctionParameters.

This will require/disallow line breaks after open parentheses of function parameters and before close parentheses of function parameters.

{
    "newline-in-function-parens": ["error", "always" or "never" or "multiline" or {"minItems": 2}]
}

• "always" (default) - Requires line breaks always.
• "never" - Disallows line breaks always.
• "multiline" - Requires line breaks when the content is multiline. Otherwise, disallows line breaks.
• {"minItems": <integer>} - Requires line breaks when the number of items is more than the specific integer. Otherwise, disallows line breaks.

Valid:

/*eslint newline-in-function-parens: ["error", "always"]*/

function foo(
) {}
function foo(
    a
) {}
function foo(
    a, b
) {}
function foo(
    a,
    b
) {}
function foo(
    a = function() {
        dosomething();
    }
) {}

/*eslint newline-in-function-parens: ["error", "never"]*/

function foo() {}
function foo(a) {}
function foo(a, b) {}
function foo(a,
    b) {}
function foo(a = function() {
    dosomething();
}) {}

/*eslint newline-in-function-parens: ["error", "multiline"]*/

function foo() {}
function foo(a) {}
function foo(a, b) {}
function foo(
    a,
    b
) {}
function foo(
    a = function() {
        dosomething();
    }
) {}

/*eslint newline-in-function-parens: ["error", {"minItems": 2}]*/

function foo() {}
function foo(a) {}
function foo(
    a, b
) {}
function foo(
    a,
    b
) {}
function foo(a = function() {
    dosomething();
}) {}

Invalid:

/*eslint newline-in-function-parens: ["error", "always"]*/

function foo() {}
function foo(a) {}
function foo(a, b) {}
function foo(a,
    b) {}
function foo(a = function() {
    dosomething();
}) {}

/*eslint newline-in-function-parens: ["error", "never"]*/

function foo(
) {}
function foo(
    a
) {}
function foo(
    a, b
) {}
function foo(
    a,
    b
) {}
function foo(
    a = function() {
        dosomething();
    }
) {}

/*eslint newline-in-function-parens: ["error", "multiline"]*/

function foo(
) {}
function foo(
    a
) {}
function foo(
    a, b
) {}
function foo(a,
    b) {}
function foo(a = function() {
    dosomething();
}) {}

/*eslint newline-in-function-parens: ["error", {"minItems": 2}]*/

function foo(
) {}
function foo(
    a
) {}
function foo(a, b) {}
function foo(a,
    b) {}
function foo(
    a = function() {
        dosomething();
    }
) {}

[ilyavolodin]

I think this is already covered by brace-style, right?

[vitorbal]

I don't think so, because it's about the function parenthesis and not the braces!

[ilyavolodin]

Oh, I see! Sorry, got a bit confused. Yes, ignore my previous comment.

[gibson042]

At the risk of sounding like a broken record, what about parentheses not associated with function declarations/expressions? Does eslint have a general strategy for style-relevant characters that appear in distinct productions (of which parentheses are just the most obvious example)?

[mysticatea]

Original JSCS rule seems to apply this rule to FunctionDeclaration, FunctionExpression, and ArrowFunctionExpression.

I think, we can add overrides option to apply for each kind.
(also, original rule can configure each paren of open/close)

{
    "newline-in-function-parens": ["error", "always" or "never" or "multiline" or {"minItems": 2} or "any"]
    // or
    "newline-in-function-parens": ["error", {
        "open": "always" or "never" or "multiline" or {"minItems": 2} or "any",
        "close": "always" or "never" or "multiline" or {"minItems": 2} or "any",
        "overrides": {
            "declaration": null,
            "expression": null,
            "arrow": null
        }
    }]
}

• "always" (default) - Requires line breaks always.

• "never" - Disallows line breaks always.

• "multiline" - Requires line breaks when the content is multiline. Otherwise, disallows line breaks.

• {"minItems": } - Requires line breaks when the number of items is more than the specific integer. Otherwise, disallows line breaks.

• "any" - Does not warn.

• open (default is "always") - Setting for the line break after the open parenthesis.

• close (default is "always") - Setting for the line break before the close parenthesis.

• overrides - We can override setting for each kind of functions. For example:

  {
      "newline-in-function-parens": ["error", {
          "open": "multiline",
          "close": "multiline",
          "overrides": {
              "arrow": "never" // or {"open": "never", "close": "never"}
          }
      }]
  }

[jesstelford]

Does this also cover newlines between arguments? If not, could we also add:

• between (default is "any") - Setting for the line break between arguments.

Valid

/*eslint newline-in-function-parens: ["error", {"between": "multiline"}]*/

function foo(
) {}
function foo(
    a
) {}
function foo(a) {}
function foo(
    a,
    b
) {}
function foo(
    a = function() {
        dosomething();
    }
) {}

Invalid

/*eslint newline-in-function-parens: ["error", {"between": "multiline"}]*/

function foo(
    a, b
) {}

---

My use-case: We enforce max-len to 100, and for longer lines we can meet that rule by doing:

someReallyCoolFunction(this.aLongPropertyName.subPropertyNamesToo,
  this.anotherPropertyName.whySoManySubPropertyNames);

Which we would like to enforce being written as:

someReallyCoolFunction(
  this.aLongPropertyName.subPropertyNamesToo,
  this.anotherPropertyName.whySoManySubPropertyNames
);

Ie; When there is a newline anywhere, everything should be newline. Otherwise, nothing should be newline.

[platinumazure]

@jesstelford Very sorry we lost track of this. I like the idea of having a separate rule for newlines between function arguments (we have a similar approach for objects via object-property-newline vs object-curly-newline). Would you like to create a new issue for newlines between function arguments?

If you can show that that was enforced by a JSCS rule, then we can flag that new proposal under the JSCS Compatibility milestone as well. If not, no worries, we will still evaluate the proposal 😄

[platinumazure]

@mysticatea I've 👍'd this issue. I'm wondering, what do you think of having the overrides be named by the JSTree node types (FunctionDeclaration, FunctionExpression, ArrowFunctionExpression)? That would be more consistent with some of our other rules.

[not-an-aardvark]

Looks like there are 3 👍s (@platinumazure, me, and @vitorbal on #6074 (comment)) so I'm marking this as accepted.

[vitorbal]

I think we still need a champion for this one, though!

[not-an-aardvark]

I'm willing to champion it, but I wasn't sure whether @mysticatea is championing it.

[not-an-aardvark]

I'm working on this.

[not-an-aardvark]

Actually, looking at this again I have a question:

The rule is called newline-in-function-parens, but it looks like it only validates parentheses around parameters, not arguments. (In other words, it applies to function declarations but not function calls.) Should we also validate arguments in this rule?

If not, I think we should modify the name of the rule to clarify that only params are checked, (and maybe have a separate rule to check argument parens).