Best practice for wrapping function arguments

[logashoff]

Style guide should advise wrapping function arguments that go over maximum line length.

function someVeryLongFunctionName(someVeryLongArgumentName1, someVeryLongArgumentName2, someVeryLongArgumentName3) {
  // Function body
}

or:

function myFunction(someArg1, someArg2, someArg3, someArg4, someArg5, someArg6, someArg7, someArg8) {
  // Function body
}

Wrapped:

function myFunction(someArg1, someArg2, someArg3, someArg4,
                    someArg5, someArg6, someArg7, someArg8) {
  // Function body
}

[elliotchance]

Is there any word on this? Compared to alternative which is common in PHP's PSR to chop down like:

function myFunction(
  someVeryLongArgumentName1,
  someVeryLongArgumentName2,
  someVeryLongArgumentName3
) {
  // Function body
}

It's better for version control to have one argument per line (the same reason we have trailing commas), is easer to read and is more friendly with default arguments.

Thoughts?

[goatslacker]

There is this: https://github.com/jeffmo/es-trailing-function-commas

[logashoff]

@elliotchance, @goatslacker Either of those is fine in my opinion.

I had Google JavaScript Style Guide in mind when I've created this issue. But Yandex approach seems cleaner. Which is similar to what you've mentioned.

[tleunen]

They should probably warn over the number of arguments instead of the number of characters.

[ljharb]

Yes - imo the problem there is that you have such a long function signature, not that it's longer than some arbitrary line length. The style guide should advise that you don't do that, instead of advising you how to paper over a bad pattern.

[logashoff]

@ljharb Agree, but it's difficult to avoid when using something like Angular with its heavy use of dependency injections. Dependency injections are also used as module imports.

[jacobp100]

Feedback on this would be good—when using flow, the functions with relatively few arguments easily exceed the 100 character limit set by the style guide.

[ljharb]

Since flow isn't a standard part of JS, this guide won't be addressing it. However, #532 (comment) seems like the least objectionable option to me.

[jmlopez-rod]

@ljharb Will #532 this make it into the style? Regardless of the framework in some cases it is very easy to exceed the character limit. Take for instance this silly example

class A {
  someVeryDescriptiveMethodAboutSomething(thisIsTheFirstParam, defaultUrl = 'https://github.com/airbnb/javascript/issues/532') {
    // ...
  }
}

applying the rule makes it more readable

class A {
  someVeryDescriptiveMethodAboutSomething(
    thisIsTheFirstParam,
    defaultUrl = 'https://github.com/airbnb/javascript/issues/532'
  ) {
    // ...
  }
}

and as @elliotchance mentioned it is better for version control. Other typed languages do have to address this issue since adding a type to an argument already takes a lot of space. Take Scala for example and the convention databricks adopted.

[ljharb]

Yes, I think that's a section we need to add - and since trailing function commas are now supported by eslint, we'd require those as well.

In other words, a section that simultaneously discourages long function signatures/calls, but describes the proper way to indent them multiline with trailing commas, would be a welcome PR.

[jakubbarczyk]

I suggest watching any talk by Kevlin Henney related to code formatting, noise and style. May be an eye-opener to some developers out there.