Live data from Hacker News

Proposed JavaScript Standard Style

github.com

31–40 of 116 posts

Re: Proposed JavaScript Standard Style

#31
post #14

Earlier quoted context omitted.

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

https://github.com/Flet/semistandard Of course the solution is to create a separate "standard."

one semicolon to rule them all?

Re: Proposed JavaScript Standard Style

#32
post #24

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.

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)

Re: Proposed JavaScript Standard Style

#34
post #14

Earlier quoted context omitted.

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

https://github.com/Flet/semistandard Of course the solution is to create a separate "standard."

this is really great.

Re: Proposed JavaScript Standard Style

#35
post #9

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

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

Re: Proposed JavaScript Standard Style

#36
post #27

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

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.

Re: Proposed JavaScript Standard Style

#38
post #20

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)

Re: Proposed JavaScript Standard Style

#40
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 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.
Post reply on HN