Better lessons from [No] semicolons in Javascript
Tags: javascript, semicolons, codestyle, decisionmaking
Published: 2020-02-06 23:41:14

---
title: Better lessons from [No] semicolons in Javascript
published: true
description: What's a better takeaway than the one[s] we pursue?
tags: javascript, semicolons, code style, decision-making
---

#### 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 pitfalls[^1] 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:

1. There's no clear winner, one way or another[^2]. (sorry!)
2. USE A FORMATTER, YOU FOOLS!
3. 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](https://en.wikipedia.org/wiki/Serial-position_effect#Primacy_effect) 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_](https://franzejr.github.io/best-ruby/idiomatic_ruby/implicit_return.html). 

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. 

```ruby
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 of[^3]; 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.

[^1]: "no semicolons" is a misnomer, as you still have to use semicolons on [certain cases](https://flaviocopes.com/javascript-automatic-semicolon-insertion/) 

[^2]: Hey look, the AirBnB styleguide makes a really great point about how you _should_ use semicolons [here](https://github.com/airbnb/javascript#semicolons). 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. 

[^3]: 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.