Space after function name

[slikts]

What's the reason why spaces after function name rule was chosen? I know this has been asked before, but I didn't see any answer. It just seems orthogonal to the purpose of a standard like this to choose something extremely uncommon in JS or even other languages.

[jprichardson]

Related: #89 #217 #311

Quoting @feross:

Let's be honest: this is an pretty unimportant issue. You might be able to find some minor reasons why your preferred style is better than the other style, but others can come up with reasons why their choice is better than yours, too.

It doesn't matter which choice we pick. Both choices are valid. Neither choice will lead to more bugs or programmer errors. So, we just need to pick something.

I like it as stated in #217 (comment)

If you adopt it, I bet you'll eventually come to like it.

[slikts]

So the answer is "just because"? It wouldn't be important if spaces after function name was something someone used, but instead it's a completely goofy choice like 3 spaces for indentation would be. I hope that this "standard" sees only limited adoption, since even if it becomes common, it will look weird to everyone new to JS.

[dcousens]

@slikts its a bike shed either way. Personally, I didn't like it at first, but, it is more consistent.
Means I can recognize function calls vs definitions very easily.

[feross]

@slikts The stats in this study show that space-after-function-name style is quite common – 33%.

If you're looking for a concrete reason why this style is better, I enjoy being able to search for function definitions vs. function invocations. With this style, it's possible to distinguish the two. For example, search myMethod ( when you want the definition, and myMethod( when you want places where the function is called.

[slikts]

Thanks, that's a good answer.

[dcousens]

last update: 2014-07-19-1
Analyzed period: 2013-07-13 - 2014-07-19

I wonder if that has changed at all with the introduction of standard @feross

[feross]

I'll email the author and see if he wants to update his stats. Might be interesting to see the change.

[rstacruz]

I'm not part of the folks who made this decision, but I can give some anecdotes. I work with a team with various degrees of JavaScript proficiency, and our codebases are often littered with both function () {, function name() {, and function() { indiscriminately.

I see function () in nameless function expressions come up very often, both in our workplace's codebases and open-source libraries. I see people happen to like that one a lot, while still write named function expressions (function name()) without a space before the parens, probably simply out of seeing that style in books and documentation examples.

I've probably done the same at some point in the past, but I really wanted to make the way I write JS consistent so I adopted the always-a-space-before style.

[tkrotoff]

@feross

The stats in this study show that space-after-function-name style is quite common – 33%

These stats are wrong: outsideris/popularconvention#62
It checks for function() vs function (), not for function foo () vs function foo() like advertised.

I did some researches: https://github.com/tkrotoff/space-after-function-name
Results: 8%

[yoshuawuyts]

@tkrotoff thanks for the information!

[tedstoychev]

@feross regarding the:

I enjoy being able to search for function definitions vs. function invocations

I would like to share a couple of other (IMO more reliable) methods:

• in ST you can hit Ctrl+R and write the name of the function. This will move the cursor to the function's definition line.
• if you have the Tern package installed in ST, whenever the cursor is on top of the function name you can hit alt+. (default keyboard shortcut) to go to its definition line (this works when the function is imported from another module too)

[myknbani]

Caught me off-guard as well. I had to search the issues for a Why? 😁

[slikts]

The answer is part bunk stats and part making definitions searchable. It's a fair guess that this decision has been one of the main reasons hampering 'standard'.js' adoption.

[mikeaustin]

In all honesty, it’s actually less consistent, and a hack to make it "searchable”. I agree with every other configuration, and I’ve also adopted trends over time (no semicolon, single quote). I’ve been a JS developer for a long time, and love the functional/immutable direction it’s headed towards.