Ternary Operators in Javascript aren’t just harmful, they’re selfish and evil

 
I recently spent many hours pouring over the CodeMirror source code in an attempt to track down a number of unpleasant bugs that turned what should have been a straightforward and quick update to my Brackets editor extension ‘Go To Matching Bracket‘ into a day-long slog.

The main reason for the wasted time? The unnecessary and excessive use of ternary operators (and ternary operators inside ternary operators inside ternary operators), whose soul intention seems to be nothing more than to obfuscate logic at every opportunity. Oh, and to save a few characters typing, because the web is short of characters and we don’t want to use them all up.

Apart from being ugly, confusing and error prone, ternary operators are a premature optimisation and usually turn simple refactoring into rewriting – they can rarely be sensibly expanded upon without reverting back to using a regular if/else statement (or heaping more stupid on top of the existing stupid).

So, next time you’re thinking about using a ternary operator, stop for a minute, read David Hayes excellent essay ‘Ternary Operators Considered Harmful‘ then… don’t. Just don’t.

Bonus:

If you’re using the excellent ESLint to improve the quality of your code then you can minimise the destruction that ternary operators wreak by enabling either the no-ternary or no-nested-ternary rule in your .eslintrc config file.


"no-nested-ternary": [2]

Add either of these rules, run ESLint in a Git pre-commit hook and you’ll never waste your colleagues time again (well, not with ternary operators anyway).

Why you can’t find that GitHub project page you’re looking for

GitHub Pages are a fantastic addition to the GitHub service. If you have already created a “read me” file for your project in Markdown format (and if not, you really should) then it takes all of 60 seconds to create a decent looking web page that is infinitely more welcoming to the less tech savvy than the ugly, cluttered mess that is the average GitHub project page. What’s more, the hosting of these pages, like the hosting of your project, is free.

A page I recently created for my Google Chrome Flashcards project illustrates what you can effortlessly create:

http://davidwaterston.github.com/GoogleChromeShortcuts

Unfortunately, there is one serious flaw in the GitHub implementation of pages – the URLs are case-sensitive.

This means that while my Chrome Flashcards page can be found at GoogleChromeShortcuts it won’t be found at GoogleChromeshortcuts (note the lower-case ‘s’ in ‘shortcuts’).

It might surprise you to hear that the W3C standard specifies that

URLs in general are case-sensitive (with the exception of machine names).
There may be URLs, or parts of URLs, where case doesn’t matter, but identifying these may not be easy. Users should always consider that URLs are case-sensitive.

Regardless, I can’t remember the last time I came across a case-sensitive URL in a public website.1 I’m very sure that most people would consider that particular “standard” absolute folly: a serious bug, a malfunction, something to be fixed and commercial suicide for most sites. With GitHub, this restriction is even more pointless as it’s not possible to create two project pages with the same name, even when the case-sensitivity is different i.e. now that I have created “GoogleChromeShortcuts” I can’t create a “googlechromeshortcuts” page. The case-sensitivity serves no purpose at all other than to frustrate users .

I wonder just how many of those 404 messages GitHub displays for pages that exist but which are hidden in the service of their adherence to a standard long since forgotten?

1 There is one notable exception – URL shorteners such as bitly.com and goo.gl rely on case-sensitive URLs to allow them to generate the greatest number of unique URLs with the least number of characters (though, notably, tinyurl.com links are not case-sensitive). For example this URL http://goo.gl/uQAJP is not the same as this http://goo.gl/UQAJP.
This is a very specific use case and doesn’t negate my original comments – GitHub Pages URLs are not the place for case-sensitivity.