Live data from Hacker News

Proposed JavaScript Standard Style

github.com

51–60 of 116 posts

Re: Proposed JavaScript Standard Style

#51
post #23

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.

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.

Re: Proposed JavaScript Standard Style

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

Re: Proposed JavaScript Standard Style

#53

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.

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

#54
post #30

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.

[deleted]

Re: Proposed JavaScript Standard Style

#55
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 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

#56
post #8

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

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.

Re: Proposed JavaScript Standard Style

#57
post #36
post #27

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

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

#58
post #30

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.

That's valid javascript, and it would produce what you expect, with or without the ending semicolon.

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()
Post reply on HN