Live data from Hacker News

Proposed JavaScript Standard Style

github.com

71–80 of 116 posts

Re: Proposed JavaScript Standard Style

#71
post #49
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.

In most cases[0], Js "looks" at the next line to see if it could continue the current statement, in which case no semicolon is inserted. [0] Not true for "restricted productions", which include naked returns, and some other "special" cases.

What do you mean?

Would

    return list.map(func1)
               .filter(func2);
work?

Re: Proposed JavaScript Standard Style

#72

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.

I really really don't understand space indentation over tabs. Every editor known to man allows you to set tabs to display with as many spaces as your heart desires. You like four spaces? Great! You like 2? Not my cup of tea, but OK! You like 8? Weirdo, but whatever! As long as your editor spits out tabs, then we can all live in harmony!

EDIT: Looks like I should have joined the fight elsewhere in the comments; please redirect discussion here:

https://news.ycombinator.com/item?id=11588783

Re: Proposed JavaScript Standard Style

#74
No semicolons? REALLY? We've already spoke about this, people.

Let's see what Brendan Eich has to say about this:

> My two cents: be careful not to use ASI as if it gave JS significant newlines. [1]

and

> ASI is (formally speaking) a syntactic error correction procedure. If you start to code as if it were a universal significant-newline rule, you will get into trouble.

Calling it "standard JS" struck me as pretentious at first. But calling it "standard JS" and calling for not using semicolons is absolutely delusional.

Let me be clear here:

- ASI (Automatic semicolon insertion) is a correction mechanism, designed to prevent silly errors, thus making the language "friendly".

- ASI does not work in many cases, where you do need a semicolon. So much for consistency!

All the rest of things in that list are just a matter of personal preference, but not the semicolons though. That's just plain wrong. And if people begin using this "standard" the bugs will come to bite them.

[1] https://brendaneich.com/2012/04/the-infernal-semicolon/

Re: Proposed JavaScript Standard Style

#75
post #69

Earlier quoted context omitted.

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…

Because a lot of JS developers have traditionally manipulated strings of HTML, which have standardised on double quotes for attributes.

Also, straight quotes as punctuation are ugly; ‘ and ’ look much nicer.

Re: Proposed JavaScript Standard Style

#77
The title is misleading. This isn't "proposed" in any relevant standards body. The project itself has a misleading name too, because it's not "standard" in any meaningful way, it's just a set of questionable personal preferences.

Re: Proposed JavaScript Standard Style

#79
post #33

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

Ok, we added "proposed". If someone suggests a better title we can change it again. If more prefixes are required I suggest "one" and "possible".

It's not "proposed" in any relevant standards body, which is why this is also misleading.

Re: Proposed JavaScript Standard Style

#80

Earlier quoted context omitted.

I agree. The number of spaces for indentation is completely irrelevant in a style guide as it can be configured in the editor on a personal basis.

No it's not, because it's not just an editor configuration, it's something in the code structure. People with different indentation working on the same files is a problem, so it's really relevant to try to set a standart about this, at least for open source project.

Yes, the code is structured with tab characters, so there is no different indentation. Only different renderings of the same semantic characters.
Post reply on HN