Live data from Hacker News

Proposed JavaScript Standard Style

github.com

61–70 of 116 posts

Re: Proposed JavaScript Standard Style

#61
post #23

I started skimming the rules and was like "this all seems fine" and then noticed "no semicolons". YOU'LL PRY THEM FROM MY COLD, DEAD HANDS FIRST

That's how I felt about spaces instead of tabs. I actually got into a Twitter argument with Brendan Eich over it - he more or less won with the note that the tab key in most web editors switches input.

I have never thought of that. Very good argument. By choosing spaces over tabs, we open up ways for contributors push code.

Re: Proposed JavaScript Standard Style

#62
While I'm not the biggest fan of this style, mostly because of the semicolon thing, I like packages like these.

When you're starting a new project with more than one developer you're going to run into people talking about this stuff more than actually making the project. Pre-bundled linting rules just gets everyone on the same page immediately and stops all the discussion.

I honestly don't care what the style is, 99% of them are sane and readable, consistency is what matters. Nothing worse than working in a project with 5/no styles all over the place.

Re: Proposed JavaScript Standard Style

#64
post #18

"Standard" for whom? This is just some guy enshrining his preferences.

Yes, basically. I actually like the premise: > No decisions to make. That can be good, certainly Go developers benefit from the lack of bikeshedding over style. But the authors of standard didn't take this advise; they did make decisions, the ones that they prefer. If they would have just grepped through NPM to figure out the most popular style choices I would have respected the idea a bit more.

The reason Go is known for this is the gofmt tool. Until there's a good equivalent for JS, thousands of man-hours will continue to be wasted on style-related nonsense like this.

Re: Proposed JavaScript Standard Style

#65

No semicolons, two space indentation, space after function name, single quotes for strings? There's no way this would fly with a majority of developers.

singlequotes for strings is very much a standard thing in JS. And two space indentation is fairly common as well. The no semicolons and space after function name are really the weird things here.

I thought so too at first, as those were the only things that disagreed with my previous style. However, I've been using "standard" for a bit now, and have to say that both of those decisions have really grown on me in light of ecma2015 features. Space after function name works well with generator functions and yield. Semicolon placement has become somewhat less consistent with the new object literal and class syntax and skipping them everywhere has saved me from constantly trying to remember whether I need one after a particular function or method definition.

Re: Proposed JavaScript Standard Style

#66
post #36

Earlier quoted context omitted.

I am well aware that we are in the minority when it comes to preferring tabs over spaces in JS, but, as useless as this decision is, I will fight over it the street. It's misplaced passion and I don't care.

I'll join that fight, unless you want you your tabs showing up as two spaces instead of four. Then we'll have to fight after we take down the spacers. On a slightly more serious note, the benefit of tabs is so clear: everyone can have whatever spacing they want and it doesn't affect anyone else. You just configure your IDE and it looks the way you want it to look. For whatever reason, indenting two spaces makes it ha…

I've always found the dislike of tabs to be quite strange. Developers love being explicit and semantic about things, and here we have a character that represents a semantic indent, and there's a huge swath of developers who prefer to go with the airy-fairy presentational space character instead. It even solves the 2-vs-4 debate with allowing each user to render it how they will. Heck, you could even render it as three spaces if you will!

It baffles me. Of course, at the end of the day it's just one IDE setting and I don't have to worry about it (we uses spaces at work and it's fine).

Re: Proposed JavaScript Standard Style

#67

"Standard" for whom? This is just some guy enshrining his preferences.

This. Calling this "JS standard!" bothers me to no end. I suppose I have to create my own style and call it "standard" too.

The benefits of a common standard language style massively outweigh the cost to you of compromising over your personal preferences.

signed, The entire Python community (well, most of us...)

Re: Proposed JavaScript Standard Style

#68
post #23

I started skimming the rules and was like "this all seems fine" and then noticed "no semicolons". YOU'LL PRY THEM FROM MY COLD, DEAD HANDS FIRST

That's how I felt about spaces instead of tabs. I actually got into a Twitter argument with Brendan Eich over it - he more or less won with the note that the tab key in most web editors switches input.

Seems like s fairly poor argument, considering most development wouldn't/shouldn't happen in a web textarea. Also, it's trivial for web editors to solve this themselves - any that don't are just lazy.

Re: Proposed JavaScript Standard Style

#69

No semicolons, two space indentation, space after function name, single quotes for strings? There's no way this would fly with a majority of developers.

singlequotes for strings is very much a standard thing in JS. And two space indentation is fairly common as well. The no semicolons and space after function name are really the weird things here.

Why would you prefer single quotes over double quotes? An apostrophe is not just punctuation in English, it is necessary to preserve the meaning of certain words (like "its"/"it's"). So in a way, it can be considered to be another, albeit rare, letter of the alphabet. Now if somebody proposed to delineate strings with the character "x" everyone would agree it's a bad idea. For the same reason, using "'" to delineate strings is also bad, and shouldn't be encouraged.

Re: Proposed JavaScript Standard Style

#70
post #30

Regarding the "no semicolon" stuff, is there actually any way to write this type of formatting list.map(func1) .filter(func2) .map(func3) .reduce(func4); in JavaScript? As far as I know, the semicolon rules would automatically terminate the statement after map(func1). EDIT: Ah, thanks – the things I read never mentioned JS doing lookahead during ASI. This makes it a lot nicer, tbh.

That pattern is valid JS, and fairly common, especially with 'functional programming' utility libraries such as lodash.
Post reply on HN