
Proposed JavaScript Standard Style - xatxat
https://github.com/feross/standard
======
kolme
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/](https://brendaneich.com/2012/04/the-infernal-semicolon/)

~~~
draw_down
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)

~~~
recursive
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!"

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

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

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

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

~~~
whatever_dude
This.

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

~~~
_asummers
[https://xkcd.com/927/](https://xkcd.com/927/)

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

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

[https://xkcd.com/927/](https://xkcd.com/927/)

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

~~~
jsmith0295
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.

~~~
Grue3
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.

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

~~~
tlrobinson
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.

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

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

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

~~~
donatj
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.

~~~
distances
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.

~~~
exprx
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.

~~~
distances
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.

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

------
shanefgan
2 spaces for indentation? No :(

~~~
arunitc
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

~~~
GrantSolar
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.

~~~
audessuscest
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.

~~~
jdmichal
Yes, the code is structured with tab characters, so there is no different
indentation. Only different renderings of the same semantic characters.

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

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

Never, you fucking monster.

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

~~~
mikewhy
... This uses eslint

[https://github.com/feross/standard/blob/master/package.json#...](https://github.com/feross/standard/blob/master/package.json#L15-L21)

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

but style-guides should be just that _style_ _guides_ ...not _standards_

~~~
draw_down
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.

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

------
Ghostium
Reminds me of that: [https://xkcd.com/927/](https://xkcd.com/927/)

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

~~~
nvader
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.

~~~
kuschku
What do you mean?

Would

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

work?

~~~
WorldMaker
Yes, but this

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

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

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

~~~
diggan
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.

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

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

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

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

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

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

------
mrighele
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](https://github.com/beautify-
web/js-beautify)

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

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

------
karn09
One (more) standard to rule them all.

------
cfluffy
standard is a really bad name for this.

