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
}
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?
There is this: https://github.com/jeffmo/es-trailing-function-commas
@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.
They should probably warn over the number of arguments instead of the number of characters.
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.
@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.
Feedback on this would be good鈥攚hen using flow, the functions with relatively few arguments easily exceed the 100 character limit set by the style guide.
Since flow isn't a standard part of JS, this guide won't be addressing it. However, https://github.com/airbnb/javascript/issues/532#issuecomment-155232701 seems like the least objectionable option to me.
@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.
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.
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.
Most helpful comment
Is there any word on this? Compared to alternative which is common in PHP's PSR to chop down like:
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?