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.
Proposed JavaScript Standard Style
61–70 of 116 posts
Re: Proposed JavaScript Standard Style
#62When 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.
Re: Proposed JavaScript Standard Style
#63No semicolons, two space indentation, space after function name, single quotes for strings? There's no way this would fly with a majority of developers.
Re: Proposed JavaScript Standard Style
#64"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.
Re: Proposed JavaScript Standard Style
#65No semicolons, two space indentation, space after function name, single quotes for strings? There's no way this would fly with a majority of developers.
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.
Re: Proposed JavaScript Standard Style
#66Earlier quoted context omitted.
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 ha…
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).
Re: Proposed JavaScript Standard Style
#67"Standard" for whom? This is just some guy enshrining his preferences.
This. Calling this "JS standard!" bothers me to no end. I suppose I have to create my own style and call it "standard" too.
signed, The entire Python community (well, most of us...)
Re: Proposed JavaScript Standard Style
#68I 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.
Re: Proposed JavaScript Standard Style
#69No semicolons, two space indentation, space after function name, single quotes for strings? There's no way this would fly with a majority of developers.
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.
Re: Proposed JavaScript Standard Style
#70Regarding 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.