Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposed JavaScript Standard Style

github.com

Post reply on HN
Print view View original

101–110 of 116 posts

Re: Proposed JavaScript Standard Style

#101

Post by emodendroket »

recursive wrote: post #99
draw_down wrote: post #94

Earlier quoted context omitted.

Everything will be fine if you don't use semicolons. My team and I haven't, for years now. It's really, really, truly honestly ok. I promise. (Only exception is for-loops)

According to the link, you have resort to this kind of weirdness in order to reliably omit semicolons. ;[1, 2, 3].forEach(bar) To my eye, having that in my code looks far worse than just using "standard" (ha ha) semicolons. You mention a for loop exception as well. I don't understand what that exception is, but the general message seems to be "Trust me, you can totally omit semicolons! Everything is ok! Except for al…

I assume it's that you have to separate the three parts of the for loop arguments with semicolons

Re: Proposed JavaScript Standard Style

#102

Post by donatj »

distances wrote: post #87
exprx wrote: post #51

Earlier quoted context omitted.

Different tab widths are a non-issue. Sure, the maximum character per line only works for a set tab width, but I take that “problem” over the rigidity (and unsuitability) of spaces as indentation.

It becomes issue when mixed with spaces. Say, aligning function parameters on multiple rows. If the indentation of the second row of parameters is mainly with tabs, and then adjusted to place with spaces, it's suddenly a huge issue. And that will happen. So spaces only for me, thanks.

Tabs for indent, spaces for alignment - solves the problem unless you're trying to align across indentation levels, but you probably shouldn't be.

Re: Proposed JavaScript Standard Style

#103

Post by bakkoting »

WorldMaker wrote: post #91
joesmo wrote: post #82

Earlier quoted context omitted.

Totally agree. It then leads to this stupidity: "Never start a line with (, [, or `." https://github.com/feross/standard/blob/master/RULES.md#semi... Now I have 4 extra rules to remember and destructuring, amongst other things, will look like shit. And for what gain? If there was an actual gain to leaving out the semicolons, I'd be onboard but the only gain here is someone's aesthetic pleasure and someone else's aest…

It's one "extra" rule. I call it the "Winky Frown Rule" or you could less cheekily refer to it as something of a "Complete Emoji Rule": lines that start with frowns (, [, ` should be winky frowns: ;(, ;[, ;` 95% of the time I ever use a winky frown is Typescript type assertions ;( someObj)... It doesn't impact destructuring at all because destructuring lines start with let (or const, or maybe var if you are feeling o…

> It doesn't impact destructuring at all because destructuring lines start with let

That's just not true. You can have destructuring assignments, not just declarations: `[a, b] = [b, a];` is perfectly legal ES2015.

Re: Proposed JavaScript Standard Style

#104

Post by tobr »

vkjv wrote: post #89
madeofpalk wrote: post #66

Earlier quoted context omitted.

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 thre…

I'm on the fence about this syntax. var foo = 1, foo = 2; The reason being that things will align whether you use a tabs with a width of 2 or 4. I also use spaces for mid-line alignment and tabs exclusively for identation. I think this is called "smart tabs"?

I don't really care if people use tabs or spaces as long as the codebase is consistent, but aligning things in the middle of a line is my pet peeve. It's fiddly to maintain, it ruins source control because it requires you to edit many lines when you change one, and worst of all, it makes it impossible to use a proportional typeface.

Re: Proposed JavaScript Standard Style

#105

Post by WorldMaker »

bakkoting wrote: post #103
WorldMaker wrote: post #91

Earlier quoted context omitted.

It's one "extra" rule. I call it the "Winky Frown Rule" or you could less cheekily refer to it as something of a "Complete Emoji Rule": lines that start with frowns (, [, ` should be winky frowns: ;(, ;[, ;` 95% of the time I ever use a winky frown is Typescript type assertions ;( someObj)... It doesn't impact destructuring at all because destructuring lines start with let (or const, or maybe var if you are feeling o…

> It doesn't impact destructuring at all because destructuring lines start with let That's just not true. You can have destructuring assignments, not just declarations: `[a, b] = [b, a];` is perfectly legal ES2015.

Fair enough, not a use case I'd encountered a need for in my code, yet. Still not that "ugly" from a winky frown perspective:

    ;[a, b] = [b, a]

Re: Proposed JavaScript Standard Style

#106

Post by draw_down »

recursive wrote: post #99
draw_down wrote: post #94

Earlier quoted context omitted.

Everything will be fine if you don't use semicolons. My team and I haven't, for years now. It's really, really, truly honestly ok. I promise. (Only exception is for-loops)

According to the link, you have resort to this kind of weirdness in order to reliably omit semicolons. ;[1, 2, 3].forEach(bar) To my eye, having that in my code looks far worse than just using "standard" (ha ha) semicolons. You mention a for loop exception as well. I don't understand what that exception is, but the general message seems to be "Trust me, you can totally omit semicolons! Everything is ok! Except for al…

(Apologies for the delay, I had to wait to respond since the lovely people in this discussion have downvoted me)

Yes, people like to bring up these goofball edge cases that don't actually happen in real life. Tell me, when was the last time you mapped over an array literal?

I'm serious, it has been years now, it is ok not to use semicolons in Javascript. People just need to... unclench. It is ok not to use them. I don't know what hellfire and brimstone people expect to happen when they stop using semicolons but it isn't going to happen.

The for-loop thing is that semicolons are required to delimit the initialization, condition, and increment of a for-loop. So you use them there.

See, this is the thing - not using semicolons to terminate statements is nicer than using them (pure opinion of course), and it doesn't cause problems in practice. But it would be ridiculous to take some hard-line stance of "absolute zero semicolons ever". The point is not that we hate the semicolon glyph or something, the point is that you don't need them to terminate statements, so we don't.

Re: Proposed JavaScript Standard Style

#107

Post by Zecc »

draw_down wrote: post #94
kolme wrote: post #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 pretentiou…

Everything will be fine if you don't use semicolons. My team and I haven't, for years now. It's really, really, truly honestly ok. I promise. (Only exception is for-loops)

    let sql = `delete from order_lines`
            ` where order_id = ${orderId}`;
Without a lint complaining about a missing semicolon you wouldn't notice this bug.

This has happened to me with a rather more complex query.

Re: Proposed JavaScript Standard Style

#108

Post by recursive »

draw_down wrote: post #106
recursive wrote: post #99

Earlier quoted context omitted.

According to the link, you have resort to this kind of weirdness in order to reliably omit semicolons. ;[1, 2, 3].forEach(bar) To my eye, having that in my code looks far worse than just using "standard" (ha ha) semicolons. You mention a for loop exception as well. I don't understand what that exception is, but the general message seems to be "Trust me, you can totally omit semicolons! Everything is ok! Except for al…

(Apologies for the delay, I had to wait to respond since the lovely people in this discussion have downvoted me) Yes, people like to bring up these goofball edge cases that don't actually happen in real life. Tell me, when was the last time you mapped over an array literal? I'm serious, it has been years now, it is ok not to use semicolons in Javascript. People just need to... unclench. It is ok not to use them. I do…

I do this... pretty damn frequently. They totally happen in my real life.

    (function(a1, a2) {
      // something
    })(arg1, arg2);

Re: Proposed JavaScript Standard Style

#109

Post by feross »

Touche wrote: post #18
emodendroket wrote: post #5

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

> If they would have just grepped through NPM to figure out the most popular style choices

This amused me, as the npm team themselves use `standard`.

https://github.com/npm/npm/blob/master/package.json#L199

Re: Proposed JavaScript Standard Style

#110

Post by feross »

kolme wrote: post #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 pretentiou…

I recommend reading the following articles before you assume that omitting semicolons is dangerous.

An Open Letter to JavaScript Leaders Regarding Semicolons http://blog.izs.me/post/2353458699/an-open-letter-to-javascr...

JavaScript Semicolon Insertion – Everything you need to know http://inimino.org/~inimino/blog/javascript_semicolons

Are Semicolons Necessary in JavaScript? https://www.youtube.com/watch?v=gsfbh17Ax9I

Spreading FUD doesn't help anyone out.

Post reply on HN