Full disclosure: I don't like semicolons in Javascript
I started like most people, using semicolons, and when I switched to no semicolons, it did feel a little strange. In time, I found I really enjoyed not having them, despite some potential pitfalls1 that I rarely [if ever] run across.
Wait! Don't go!
Believe it or not, this is NOT just another article about semicolons in Javascript. This is really about a tool you can use when trying to make decisions with your team.
Actually, this is actually an article about something far more ambitious:
I want to propose a tool to help you make decisions in things outside code as well.
Ok, this is likely a promise I can't deliver on, but bear with me for a bit; for now let's just take that statement as a clear LIE, and maybe by the end of the article we'll see just how true [or false] it is. Thank you for reading! You're the best!
How this started
I'm not a great Javascript programmer. If I had to describe myself, I would say I'm just someone who hangs in there.
One day, my brilliant devops manager dropped in some code to standardize and set up the codebase properly. One of his changes was to take out all my custom linter rules [like semi: never'] in favor of the standard, out-of-the-box rules.
Not being a great Javascripter, I thought maybe he knew something I didn't, but it turns out that wasn't the case, and so the discussion began:
Our individual points, boiled down
ME: "WAAH! I don't want to use semicolons!"
DEVOPS: "Uh, Javascript uses semicolons, my dude."
And thus, the research began! To the Internet!
The resulting research
I'll spare you the headache of having to look all this stuff up on your own with a nice, easy, bulleted list of what we found:
- There's no clear winner, one way or another2. (sorry!)
- USE A FORMATTER, YOU FOOLS!
- People who write about this claim they don't really care, but their words usually betray a clear preference - one that if they had to go against, they would very much grit their teeth through.
So which should we use? I don't know the answer for you or your team, but this was a good opportunity for me to apply a tool I've been using for the past 6 years to police my thinking somewhat.
The Tool
You made it this far. Thank you. Here's the tool I was talking about earlier:
When given an option to switch to something else, flip the history and see if your opinion changes.
This tool has been invaluable to me in making decisions, and in policing myself when I find myself resisting change. "We've always done it this way!" isn't useful in life, let alone in the ever-changing world of computing.
Putting it to the test
Let's take this thing out for a spin, shall we?
Let's flip the history of Javascript semicolon policy. Let's say that Javascript always had the policy of "no semicolons"1.
One day, maybe a decade ago, someone pitches the NEW idea: "Explicit semicolons!". Now, we can finally start adding them, not just to the edge-case lines in our code, but to every line that we feel should have explicit termination. And obviously, we're not dummies, so we'll get our formatter to do it for us as well, just as we do now. Better, right?
Yes? No? Maybe?
Regardless of what you choose, we've removed the condition of which came first as a criteria for which version to implement. Because primacy is a real thing that we're all going to struggle with, so it's great to have tools to address it when we can.
I've struggled with this before
When I moved from PHP to Ruby years ago, Ruby introduced me to the world of implicit return.
The dirty summary of implicit return is this: Ruby will automatically return the last line automatically.
Now, if you were like me, you would probably have thought "This is crazy. I'm gonna be making mistakes all over the place". In a small way, you're right. After programming in Ruby for ~15 years, I can tell you there are plenty of times where I've accidentally screwed myself by putting a logging statement at the end of a method, and then wondered why the method was returning the wrong value.
def allow_mega_super_access?
@user.admin?
Logger.info("Only super-privileged users should get through! WE ARE SOOO SECURE!")
end
And yeah, I have fun dreaming up the worst example I can think of, but you know what? I make mistakes constantly, and when weighing all the mistakes I've made from my improper use/reading of implicit return VS all the benefits I've garnered from implicit return, the tally isn't even close. Implicit return is the bees knees, y'all.
And when I apply the tool and flip history - either way I flip it, implicit return is the reigning champ in my mind, hands down. I wish all languages had this. Of course, your results may vary.
But let's take a look at this tool outside of the realm of programing, as promised.
I seriously just applied this technique as I was writing this article
Ok, in some kind of cosmic lesson, I self-applied this rule to this very article as I was writing it.
In my original draft, I was using title-case For All My Headings and Titles. In the middle of writing one of the headings, I asked myself, "Is title-case better?" Even if it is considered grammatically correct, should I use it?
So, once again, I flipped history to see if my opinion changed:
What if we had always used "Sentence-casing" for our titles, and someone, very recently introduced the idea of using title-case. Would we see that as a better alternative?
Now there might be really great reasons to title-case your headings that I'm woefully ignorant of3; if that's the case, I hope those really great reasons will inform my future self when I re-evaluate based on that new information.
For now though, my only reason to use title-case for headings is "It's always been done that way".
And if that's true, then it might be time to re-think that idea.
PLEASE UNDERSTAND: This is not a silver-bullet for decision making!
What this is is a tool to minimize primacy/recency from your decision making. That's it.
You don't have to defend against it or for it, because, as of now, it is your own thought-experiment. Yours. Use it as you see fit.
Promise kept?
That's it. Hopefully you found/find value in the tool I mentioned, and my ambitious statement at the top wasn't too much of a lie. The only way to know is to try it.
Thanks for listening.
-
"no semicolons" is a misnomer, as you still have to use semicolons on certain cases ↩
-
Hey look, the AirBnB styleguide makes a really great point about how you should use semicolons here. The dirty summary being javascript changes a lot; semicolons keep us safe[r] during these changes. Which is weird, because the ready-acceptance of all the constant javascript changes is actually a big part of why I think I should not use semicolons. ↩
-
I bet Chicago and AP style-guides have reasons - reasons I would probably look up if I was a diligent writer... Which kind of makes this "footnote" completely worthless when you think about it. ↩
Top comments (1)
I like the point of the article, which boils down to a way to challenge your presuppositions.
I disagree with your stance on semicolons and implicit returns, though.
Setting aside personal preference, there are 2 reasons to use semicolons. First, the parser never has to run the checks for ASI. Second, your code always does what you think it does. If you don't like typing them, just set up your linter to insert them, and you remove the chance of any bugs from ASI rules. So, to me, it's a simple comparison. Not using them adds a chance of bugs. Using them doesn't add any chance of bugs. That's a clear winner in my book.
The same goes with implicit returns. The benefit of not having to type the word "return" is very minor compared to the chance of a bug. The number of keystrokes you're saving is minuscule compared to the chance of bugs from returning the wrong thing. Additionally, it makes your code harder to read. Seeing "return" makes it very obvious what is happening. Implicit returns take up more discrete quanta in your mind, thus making it more difficult to keep the code in your mind. Again, the small benefit compared to the chance for (potentially really bad) bugs and making code hard to read makes this a no brainers for me.
I'm all about saving keystrokes, which is why we default to single quotes for strings (no shift key), but not at the expense of readability or possibly introducing a new class of bugs that can't exist otherwise.