Re:Proposed JavaScript Standard Style
by emodendroket on Thursday April 28, 2016 @09:33AM
(#11588656)
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).
Re:Proposed JavaScript Standard Style
by emodendroket on Thursday April 28, 2016 @09:41AM
(#11588718)
https://github.com/Flet/semistandard
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.
Re:Proposed JavaScript Standard Style
by Rick-Butler on Thursday April 28, 2016 @09:47AM
(#11588765)
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.
Re:Proposed JavaScript Standard Style
by strictnein on Thursday April 28, 2016 @10:01AM
(#11588888)
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.
Re:Proposed JavaScript Standard Style
by madeofpalk on Thursday April 28, 2016 @10:14AM
(#11588983)
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.
var
foo = 1,
foo = 2;
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.
Re:Proposed JavaScript Standard Style
by abecedarius on Thursday April 28, 2016 @10:56AM
(#11589300)
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.
Re:Proposed JavaScript Standard Style
by madeofpalk on Thursday April 28, 2016 @10:20AM
(#11589018)
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.
Re:Proposed JavaScript Standard Style
by forthefuture on Thursday April 28, 2016 @09:59AM
(#11588872)
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.
Re:Proposed JavaScript Standard Style
by andremendes on Thursday April 28, 2016 @10:03AM
(#11588904)
I have never thought of that. Very good argument. By choosing spaces over tabs, we open up ways for contributors push code.
YOU'LL PRY THEM FROM MY COLD, DEAD HANDS FIRST