Earlier quoted context omitted.
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.
Proposed JavaScript Standard Style
51–60 of 116 posts
Re: Proposed JavaScript Standard Style
#52As 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.
Re: Proposed JavaScript Standard Style
#53No 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
#54Regarding 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.
Re: Proposed JavaScript Standard Style
#55I 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
#56Earlier quoted context omitted.
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.
Re: Proposed JavaScript Standard Style
#57Earlier quoted context omitted.
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.
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.
Re: Proposed JavaScript Standard Style
#58Regarding 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.
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 list
.map()
.filter()