Hacker News new | past | comments | ask | show | jobs | submit login
Proposed JavaScript Standard Style (github.com)
29 points by xatxat on Apr 28, 2016 | hide | past | favorite | 110 comments

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]


> 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/

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.

I know I can write a working JS application without semicolons, however I can also write a working JS application where with `eval` and `with`.

The issue is not whether or not one individual can learn to use dangerous feature X. If you are writing code by yourself for your own use, you can use nested eval's and no semicolons with a little bit of `with` here and there, nothing wrong with that. However when you are writing code that is supposed to be developed by people other than you, you might want to write less clever code.

I could write code without semicolons, however that would mean that I would have to constantly keep an eye out for that case where I absolutely need to add it to prevent ASI from doing the wrong thing. It takes probably 100ms to hit that semicolon key, however it takes a lot more time to debug code without semicolons.

If you hat semicolons with a passion for some reason, you could use Coffee Script or some other language which was designed without semicolons and has clear semantics around it.

I think the keyword in Brendan Eich's article is maybe "be careful" rather than "don't use". Overall, Brendan Eich is mostly positive on ASI (otherwise the language wouldn't have it) and some of the article is about how if things had been left to cook longer it's just as likely JS would be a more newline-sensitive language than it is.

Particularly interesting too in the article linked is the link to the paren-free strawman proposal [1] that suggests maybe its past time that JS also drop the algol-family heritage require parentheses in the head of for/while/if for whitespace sensitivity instead (ala CoffeeScript, golang).

[1] https://brendaneich.com/2010/11/paren-free/

Crockford on Bootstrap's semicolon omission: “insanely stupid code”


The answer from @fat is face-palm worthy:

> i have learned to use them, that's why there isn't one present.

Did you, really? Because that's how that bug came to be. Because of you stubbornly omitting them.

Why do these people want to avoid semicolons at all costs? Even inconsistencies? Even potential bugs? Why?? I just don't get it.

I need to leave this discussion, I'm getting nerd-rage.

Yes, let's see what Brendan Eich has to say about this.


^ Brendan's own company (Brave) uses `standard`, so it's clear he doesn't think omitting semicolons is so bad.

This is the modern version of tabs vs spaces.

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 aesthetic displeasure. Last time I checked, code was there to do things, not look pretty. Making the former more difficult to achieve the latter is not only stupid, it's impossible because now you're pandering to fashion which varies from person to person. Also, it's bikeshedding. As if Javascript didn't have real problems it needs solved.

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 ;(<any>someObj)...

It doesn't impact destructuring at all because destructuring lines start with let (or const, or maybe var if you are feeling old school that day).

ASI is not very different at all from the newline rules in Python, ML, Haskell, et al... Freedom from semicolons makes ES2015 feel like the OCaml derivative it always sort of has been.

> 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]

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 all these weird edge cases, but you can just hack kludges around them!"

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

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

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

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

    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.

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

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


Grep through the npm ecosystem, as that serves as a large sample size of what are the standard style choices. I know that npm and it's largely unreadable codebase uses your style.


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

Maybe we can also standardize this exact post since there have already been like five of them.

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.

This is addressed in the README

  But this isn't a real web standard!
  Of course it's not! The style laid out here is not affiliated with any official web standards groups, which is why this repo is called feross/standard and not ECMA/standard.
  The word "standard" has more meanings than just "web standard" :-) For example:

  This module helps hold our code to a high standard of quality.
  This module ensures that new contributors follow some basic style standards.

I don't claim a project has to be an "official" Web standard to be a standard, but I'm seeing a hard time how this one is a standard in any meaningful sense.

This is not a solution to any problem, except the problem of not enough standards


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:


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.

There's also the subtle laziness that double quotes require an extra keypress (Shift). It's not a great reason to prefer single quotes over double quotes, but it is a useful reason if you are writing a lot of strings.

JS has a lot of things that key off strings (because it doesn't have a proper enum type and the Symbol type is too new for a lot of usage yet), so you type a lot of "non-English text" strings, so single quotes make a lot of sense for the majority of uses of strings in JS. English text I typically still "double quote" or `template string quote`.

Until you mentioned it I was not even conscious of the fact that double quotes required pressing shift, yet I type hundreds of them every day.

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.

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.

Two space indentation is a deal breaker for me.

Funny that a project that is supposed to fight debates about style, creates so much debate!

As a experience of actually adopting standard (this very project) in a company, I must say it's refreshing to not having any discussions about coding style anymore.

Process before was to discuss which eslint rules we want to follow and then sometimes it changes. With "standard", we just asked ourselves "Can we adopt these rules and stand with them?". Most people agreed and then we implemented the support company wide and now we never discuss coding style in our javascript projects anymore, which is a pleasure.

If you find yourself discussing coding styling, see if you can adopt something like standard, and then just go with it.

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.

I started skimming the rules and was like "this all seems fine" and then noticed "no semicolons".


That is a really bizarre choice since I think "no semicolons" is the less popular position by far.

Let's just say that coupling this preference with the name "standard" is an extremely contentious decision (search the github issues).


Of course the solution is to create a separate "standard."

This is great, but I don't like the space between function names and arguments.

I'm going to fork this and create my own standard...

this is really great.

one semicolon to rule them all?

Maybe if I was using Python or Ruby. But JS? REALLY ugly practice. Multiple blank lines not allowed? I usually go with two to segment heavily procedural code. The most appalling thing by far though is spaces instead of tabs... what's wrong with this guy?

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 hard for me to read code.

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

I'm on the fence about this syntax.

        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.

It's very common to find mixed tabs and spaces where people use tabs. The first sign of this is inconsistent indentation. Maybe they're just sloppy? Oh, hm, here's some more code where it's wildly inconsistent. Time to play guess-the-tab-width until it settles down. Now should I add a comment at the top to tell Emacs about this setting next time I open the file? Probably not, sigh.

Semantic tabs would be good with consistent culture and tooling behind them.

I hope they enjoy their subtle and extremely hard to find errors.

They address this directly - the only edge case with omiting semicolons is starting lines with ( or [ and they check this for you. See: https://github.com/feross/standard/blob/master/RULES.md#semi...

I alternate between projects with and without semicolons, and I'm yet to run into a single error as a result of omitting a semicolon. I don't understand what kind of code other people are writing that does.

Could you cite some examples? It seems that using the rest of the conventions might eliminate many, if not all, of them.

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.

I used to like tabs. Then you have a person or two with different tab widths, and some spaces get mixed in, and the beauty of the idea flies out of the window. I've been all spaces for a long time now.

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.

I don't know about others but jsbin, codepen, and c9.io all have e.preventDefault on tab because it's trivial and many people still use tab.

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

no semicolons = no deal

2 spaces for indentation? No :(

I always use a tab and set the IDE to show two spaces for each tab. Visual Studio has a setting for this. In the same project if someone wants 4, they can just change it to 4 spaces. In the file, its always stored as a tab

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.

which lead to very useless and annoying conflict and different coding style in same files

I'm all about two spaces but this is a pointless argument

My first thought as well

> Space after function name function name (arg) { ... }

Never, you fucking monster.

Use this if you want the readme badge. Use eslint if you are serious.

Airbnb has a decent styleguide - https://github.com/airbnb/javascript "A mostly reasonable approach to js"

but style-guides should be just that style guides ...not standards

The idea is that you stop trying to have humans match the style guide, playing trial-and-error with the linter, and instead just have a tool fix the style. We have more interesting problems to solve than matching the style guide. Computers can take care of that.

Plus then you don't have to talk about it in code reviews. It's not a very interesting topic, honestly.

I switched to this style a few months ago, and really like it. Makes javascript read more like python, clean and specific.

Downside is that very few other authors are using it, so when you share code people are concerned about its format (no semicolons in particular).

Reminds me of that: https://xkcd.com/927/

Regarding the "no semicolon" stuff, is there actually any way to write this type of formatting

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's valid javascript, and it would produce what you expect, with or without the ending semicolon.

Here is an example: http://jsbin.com/mokipigeqa/edit?html,js,console

Here are the ASI-relevant parts of the ES5 standard: http://es5.github.io/#x7.9

In JavaScript, LineTerminators are used as a separator between tokens, just like other whitespace is. Therefore:

  list .map() .filter() 
is equivalent to


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?


    return list.map(func1)

Yes, but this

has never worked in the history of JS because JS terminates the return at the newline and returns undefined.

It depends on the engine, but most, when parsing, will look-ahead and see that `.` in `.filter(func2)` is an invalid start to an expression and assume it is part of the previous line.

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

No, ASI (automatic semicolon insertion) does not insert a semicolon on the first line (or the 2nd or 3rd) in this case.

The code works as expected.

That's fine in JavaScript and will work as expected.

I've been lucky enough to avoid having to deal with a style guide in a long time. The general idea is sound, but such a guide is always accompanied by hours-long meetings of senior developers hurling their egos at each other over an issue like semicolon usage. Such a waste of everyone's time.

Yeah, that's the whole point of this "standard" project. So instead of adopting for example eslint and then sit in a meeting and decide which rules to follow or not, you adopt standard and say, we are using this now, deal with it.

I mean, eventually you've got to make decisions; you can't all just be writing with your own style (I've experienced that scenario and it really obscured meaningful changes to have tons of style changes in each commit)

In case it's not obvious, this is definitely not a "standard" of any kind. It was named "JavaScript Standard Style" as a joke, and has since become moderately popular.

I disagree with some of the rules, but there's clearly merit to having one opinionated, zero-configuration linter-enforced style.

This seems like a great style, but it's not going to catch on because it's a separate dependency. If this were distributed as a configuration file for the most commonly used linters, I'd be interested. Since it's its own linter with its own plugins etc, hard pass.

There's ESLint config available too: https://github.com/feross/eslint-config-standard (and a React flavor for it too under eslint-config-standard-react)

Why is this posted under the title "Proposed JavaScript Standard Style"? I am the author of `standard` and I did not propose that this becomes any kind of official JavaScript style standard. It's just my own code standard -- you're free to use it if you want.

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.

There's no real good reason why, but my mild OCDish tendencies get intensely triggered by looking at Javascript with no semicolons.

We have been using for some time js-beautify [1] together with a pre-commit hook to enforce the style of our JS code. This doesn't seem much different, am I missing something ?

[1] https://github.com/beautify-web/js-beautify

Well, I like it... but it's pretty much the style I'm already using.

This is what my team and I have used for a while now. It's nice. I recommend it.

edit: ha, I got downvoted for saying something is good and recommending it. You guys are silly

One (more) standard to rule them all.

standard is a really bad name for this.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact