Is readability always better?

September 30, 2022 - conference javascript coding yow

At the recent YOW Perth conference, Andy Marks & Pam Rucinque of Thoughtworks presented a thought-provoking talk on "Reviving the art of software design". As part of the talk they had a selection of different-but-functionally-identical implementations of a pangram-checking function, and attendees were asked to vote on which one was best.

The following implementation received the most votes (I note at its origin on it’s the most popular solution there also):

export const isPangram = (input) => {
  const inputLowered = input.toLowerCase()
  return [..."abcdefghjklmnopqrstuvwxyz"]
            .every(c => inputLowered.includes(c))

I can easily understand why people voted for it - I think it hews closely to most developers’ internal mental models of how to solve the problem, and we view it as the most ‘readable’ or ‘understandable’ implementation. It is also influenced by what we currently think of as good programming techniques, perhaps 10-15 years ago we would have seen a for loop there instead.

However, I would posit this is not good code (or at least, that there are much better solutions out there). The reason is that I’ve introduced an intentional bug in the above version and I’m betting most readers didn’t spot it - I've dropped the i out of the alphabet string, perhaps this was a fat-fingered delete when copying & pasting from StackOverflow. The function will now return false positives in a very small number of cases, however I suspect this code would make it through code review 9 times out of 10, and will probably pass all of the unit tests. (If you’d written property based tests you’d pick up the bug, but inexplicably most developers still aren’t writing these.)

What’s interesting to me is that we know honking great big magic string literals in code is bad design, but most people still chose this design anyway. I believe now we’ve had decades of indoctrination in the primacy of code readability, we may have reached a point where the perceived readability/understandability of code trumps every single other consideration, even when the code is qualitatively worse. Now I concede I’ve seen some pretty awful crimes against readability in an attempt to guard against obscure bugs (eg a lot of 90s-era coding standards), but I feel we could have lost balance here.

Older posts

Blog Necromancy

September 26, 2022 - 585 words - 3 mins
I realise this blog has been quiescent for over half a decade, but I've resolved to put a little bit more time into blogging, professional development, and other not-directly-billable pursuits. There are a number of factors behind this; chief is probably that I'm not really using Twitter anymore (th… read more

RxSwift DelegateProxy with required methods

May 12, 2016 - 350 words - 2 mins
Once you’ve sipped from the Reactive Kool-Aid it can become emotionally painful to have to implement callback methods the old-fashioned way when you hit a delegate-style API that doesn’t have a prebuilt Observable wrapper. Max Alexander did a great tutorial post on how to implement your own Delegate… read more

Swift ErrorTypes - A Modest Proposal

October 02, 2015 - 790 words - 4 mins
After the WWDC announcement, when I got over my initial knee-jerk ‘Exceptions - ick!’ reaction, I came around to being a supporter of the Swift 2 error handling model. While it would be nice to be able to desugar the implicit result type, and there’s a glaringly obvious hole with async error handlin… read more

Using Xcode Playgrounds for Presentations

September 08, 2015 - 359 words - 2 mins
Playgrounds are primarily designed as a learning tool, but with Xcode 7’s multiple pages and expanded rich markup support, they’re also really great for presentations - they allow you to mix slide-like text & image content with interactive code (for coding demos). Because everyone loves coding … read more