New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Space after function name #318

Closed
slikts opened this Issue Nov 5, 2015 · 14 comments

Comments

10 participants
@slikts
Copy link

slikts commented Nov 5, 2015

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

This comment has been minimized.

Copy link
Member

jprichardson commented Nov 5, 2015

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

This comment has been minimized.

Copy link
Author

slikts commented Nov 5, 2015

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

This comment has been minimized.

Copy link
Member

dcousens commented Nov 5, 2015

@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

This comment has been minimized.

Copy link
Member

feross commented Nov 5, 2015

@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.

@dcousens dcousens added the question label Nov 5, 2015

@slikts

This comment has been minimized.

Copy link
Author

slikts commented Nov 5, 2015

Thanks, that's a good answer.

@dcousens

This comment has been minimized.

Copy link
Member

dcousens commented Nov 5, 2015

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

This comment has been minimized.

Copy link
Member

feross commented Nov 5, 2015

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

@rstacruz

This comment has been minimized.

Copy link
Member

rstacruz commented Nov 5, 2015

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

This comment has been minimized.

Copy link

tkrotoff commented Jan 17, 2016

@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

This comment has been minimized.

Copy link
Contributor

yoshuawuyts commented Jan 17, 2016

@tkrotoff thanks for the information!

@pretodor

This comment has been minimized.

Copy link

pretodor commented Oct 10, 2016

@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

This comment has been minimized.

Copy link

myknbani commented Aug 4, 2017

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

@slikts

This comment has been minimized.

Copy link
Author

slikts commented Aug 6, 2017

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

This comment has been minimized.

Copy link

mikeaustin commented Feb 17, 2018

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.

@lock lock bot locked as resolved and limited conversation to collaborators May 25, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.