“No semicolons” is the opposite of practical

[gaearon]

Adopting standard style means ranking the importance of community conventions higher than personal style.

README

I assume a standard that calls itself “standard” would choose “practical” over “fancy” every time.
It does so, except when it comes to semicolons.

Consider these two rules:

• No semicolons – It's fine. Really!
• Never start a line with ( or [

They can be substituted by one simpler rule:

• Always put semicolons between statements.

The “never start a line with ( or [” rule is very arbitrary.
It is only going to get worse with ES6 where

[a, b] = something();

is a valid destructuring construction.

Isn't it strange to write

{ a, b } = something()
;[a, b] = something()

thus making code less uniform, if you can make it more uniform by just writing semicolons?

{ a, b } = something();
[a, b] = something();

I understand you probably have feelings about this subject, so I don't really expect this to be considered.

Still, it is unfortunate for the subjective aesthetics to triumph over the objective simplicity in something called a “standard”.

[yoshuawuyts]

If semicolons are your thing, take a look at semistandard.

[dcousens]

Duplicate of #5 ?

[maxogden]

There are just as many if not more arbitrary rules when using semicolons.
The point of standard is to avoid issues like this

On Tuesday, March 24, 2015, Daniel Cousens notifications@github.com wrote:

Duplicate of #5 #5 ?

—
Reply to this email directly or view it on GitHub
#78 (comment).

Sent from my phone

[callumacrae]

There are just as many if not more arbitrary rules when using semicolons.

Such as? What does "Always put semicolons between statements." not cover? 😃

[gaearon]

There are just as many if not more arbitrary rules when using semicolons.

I don't think so. Can you name one?

[maxogden]

For example, you have to remember to not do this:

function () {

};

But remember to use them here:

var obj = {

};

If you don't like standard, by all means don't use it. Those of us that do use it don't want to argue about semicolons. it's a waste of time

[callumacrae]

Well, only one of them is a statement (you're talking about function declarations, right?). "Always put semicolons between statements." still works for that.

You can't call a coding style "standard" and then suggest that the majority of people don't use it. That's how you hurt beginners.

EDIT: Yeah, 85% of DailyJS survey respondents said they use semi-colons. This "standard" isn't standard at all.

[gaearon]

For example, you have to remember to not do this

There's nothing arbitrary about it.
Unlike the arbitrary [/( rule, the statements that need ; after them are in the spec.

[yoshuawuyts]

I think we can all agree that the JS syntax isn't the cleanest, if it was we wouldn't have need for a style guide in the first place.

That said, if your goal is to change standard to adopt semicolons, I'm confident it's not going to happen. Instead of pointlessly arguing over punctuation, consider adopting a style guide that better suits your style such as semistandard or idiomatic.js.

[callumacrae]

My problem with this style guide is the name, not the lack of semicolons. Of course you're free to create a style guide that bans semi-colons!

What I have a problem with is calling a library "standard" and then requiring something that the majority of developers disagree with. That is not a standard. This is harmful to beginners, and I have seen this affect people in real life.

Of course people are going to choose the style guide called "standard". It's just a shame that it isn't.

[callumacrae]

What I would propose, as a compromise:

• Have no rules about semi-colons.
• Tell users that they're completely optional, but most developers use them.
• Have two flags, --no-semicolons, and --semicolons, the former banning semi-colons and the latter requiring them.

[yoshuawuyts]

@callumacrae The first rule of standard is:

No configuration.

[callumacrae]

Then the name should be changed. It's misleading to call something standard if it isn't. You get a little bit of leeway, but when 85% of developers do it a different way, that definitely isn't standard.

[gaearon]

My problem with this style guide is the name, not the lack of semicolons.

Exactly. It's claiming to be something it's not. It's obviously doing this intentional, with all the badges and marketing messages in README.

It's actively misleading.

[maxogden]

@callumacrae @gaearon if you don't like it, don't use it. You energy is being wasted here. @feross' repos aren't governed by a democratic process.

[callumacrae]

You don't care that this is going to harm beginners?

[maxogden]

@callumacrae That's your opinion. You have shared it multiple times. Thank you for sharing.

[pbrinkmeier]

Guys I know this is the internet but standard is in this case just a name ... do you complain when Apple does not actually sell apples, too?

[maxogden]

Also this is a contrived example:

[1,2,3].map(...

I'm taking it out of the readme, there is no excuse to start lines with [ or (. It's only useful when writing overly terse/clever code.

[maxogden]

Thanks everyone for their valuable feedback. Closing this as we have proven that practicality is in the eye of the beholder.

[gaearon]

there is no excuse to start lines with [ or (. It's only useful when writing overly terse/clever code.

Have you read the example in my post? It's ES6 destructuring.
It's a language feature, not “overly clever code”.

[a, b] = c;

[gaearon]

Anyway, I see now that standard knows which features are useful better than ES6 authors.
Thanks for the consideration!

[jlongster]

Why... why do you all choose to ignore a fundamental feature of ES6 which many people are using today?

[Fishrock123]

The better question would be, does destructuring:

noSemicolon()
[a, b] = c // destructuring

have the same drawbacks as:

noSemicolon()
[a, b] // actual array

The second will be interpreted as a single line, ala noSemicolon()[a, b], would the former be any different?

[KidkArolis]

@gaearon @jlongster a serious question - do you actually ever do [a, b] = c, or would it always be let [a, b] = c or similarly prefixed?

[callumacrae]

[a, b] = [b, a] is a good way of switching two variables around, so yeah

[jlongster]

@Fishrock123 just tested it, and this works:

var z = 5
var y = z
[ x ] = [5]
console.log(x)

However, this still breaks:

function foo() {}

foo()
[ x ] = [5]
console.log(x)

/*
Exception: TypeError: foo(...) is undefined
*/

I'm sorry, I just think you all are introducing a lot more subtle bugs here.

[caspervonb]

When you pick a package name like standard, and marketing it as the standard style, with it showing up as first rank on Google on at least a couple of queries. It's actually really harmful to be promoting pre assembled footshotguns.. no? Most readers will probably just read the readme and walk away with that knowledge that this is the standard way of doing things.

[gaearon]

@KidkArolis

Good point. I don't use this form because I const wherever possible and almost never let or assign. Some people are more pro-mutability though, and it indeed is the idiomatic way to swap variables.

I understand this tool catches this error, but this project is clearly more than a tool.

It markets itself as a standard:

Experienced JS developers won't fall for this (there's nothing standard about no-semicolons, which is precisely why insisting on them always creates controversy). But beginners may think “standard” (without any capitalization or emphasis in your marketing texts) is indeed the universally agreed “community convention” (from your README), which it isn't. Beginners might then adopt your conventions without using your tool. Which brings them to subtle bugs. For what?

Bottom line, it's not nice to call something standard if it's not.

Especially when “standard” looks like an objective description and not a name, which it really is:

[jlongster]

Yeah, you all need to double-check your own preferences. This is clearly a case where you are pushing your own preferences and labeling it the standard within the JS community, which it is clearly not. The majority of the JS world uses semicolons, so if you really are wanting to make a tool for the community, you would forgo your own personal preferences in lieu of the community's.

[jamiebuilds]

Closing this as we have proven that practicality is in the eye of the beholder.

So not a standard? Okay.

[gaearon]

To clarify, I don't expect any kind of democratic process around that. I'd say there are several possible options.

1. Admit that semicolons are more “standard” in the community, bump major version and provide migration instructions.
2. Change the name to reflect that this style is opinionated.
3. Do nothing.

[Fishrock123]

@jlongster Right, because it still sees it as <output of foo>[at index x] = [5]. :|

However, this still works:

function foo() {}

foo()
var [ x ] = [5]

I'd suspect this would be the more common case, though that might not be true.

To me, ;[destructure] in the case where I am setting already defined variables seems acceptable to omitting semicolons regularly. It looks like an array to me so I'd personally insert the leading semicolon automatically anyways.

(This is under my thinking I'll usually just define the variables where I define them, ala var [x, y] = vec.)

[KidkArolis]

@jlongster but in this case, standard would warn you to prefix [ with ;? I know you guys still don't agree with that, but I'm just trying to assess the "safety" of the semiless approach.

[KidkArolis]

Ignore my comment - github cache..

[jlongster]

as @callumacrae mentioned, it's nice to swap variables with just [a, b] = [b, a]. It's not entirely uncommon.

Also, is this considered starting a line with [?

callFunctionLotsOfArgs(
  foo,
  bar,
  baz,
  [ bizzle ]
)

[jlongster]

For what its worth, I'm sorry for the tone of my recent comments, particularly #78 (comment). Hope you'll forgive me, I'm a little hyped today. We are all part of the same community and I know you all are working hard for everyone else :)

[selfawaresoup]

Regardless of any semicolons or other specific rules, calling this a "standard" is highly misleading and frankly, a case of hubris.

Unless proposed by a governing body (ECMA) a style guide is just that: a guide. Especially, if it's written my mostly just one person.

[RReverser]

Unless proposed by a governing body (ECMA) a style guide is just that: a guide. Especially, if it's written my mostly just one person.

This! You can't just release something in regard to language that has own organization defining the real standards, and call your thing "standard", even if it's just a coding style. It's not the way standards are created.

It's just the same as if I would define own extensions on top of ES5 and call it "ES6 standard" - that would be wrong, misleading and harmful.

[freeall]

I feel like throwing a "promises or callbacks?" into this discussion.

[Fishrock123]

Also, is this considered starting a line with [?

@jlongster Nah, it's only for ones inside code blocks (including global), not as parameters.

[dcousens]

It only warns you to do that if necessary. The linter can see any
issues long before you can, this entire problem is moot.

Standard is a standard, it may not be yours, but that doesn't matter, as
it is mine, and it is others.

Beginners won't get hurt if they use the tool as specified. Remembering,
this is, in fact, a tool.
On 25 Mar 2015 6:43 am, "Karolis Narkevicius" notifications@github.com
wrote:

@jlongster https://github.com/jlongster but in this case, standard
would warn you to prefix [ with ;? I know you guys still don't agree with
that, but I'm just trying to assess the "safety" of the semiless approach.

—
Reply to this email directly or view it on GitHub
#78 (comment).

[maxogden]

Locking due to excessive bikeshedding + haters

If you like arguing about semicolons, standard isn't for you. Please take the discussion elsewhere