Double the code, double the readability?
If you could improve readability by doubling the amount of code, would you still do it? It's a rhetorical question. Of course you wouldn't. I mean, you wouldn't, right?
The two comboboxes
Recently, I've been tasked with creating a combobox implementation for the accessibility project I'm working on. The one that is being used right now isn't quite accessible (it comes from a popular UI toolkit, but let's not name names, because the alternatives are mostly similarly inaccessible anyway). As usual, I went for the WAI patterns website website to see what they do.
They had a few great examples. I tested them with the screen readers, and they worked much better than I hoped. That pleased me. Then I looked at the source code. It looked to me like they had a lot more code than I expected for such functionality, so I decided not to use it. From my experience, this gut feeling never let me down. Whenever I see something that looks like "too much code", I'm usually right.
Their implementation has around 600 lines of code, amounting to about 15kb or raw payload. The version I ended up with has around 230 lines of code amounting to about 7kb. I count comments towards the line number in each case — and my version has more comments — because we are talking about readability here, and comments are there to (hopefully) improve it. So the WAI version is roughly 2.5× more in lines, and 2× in payload.
For reference, here are the examples:
You will see I do lots of things that many developers consider dirty, like using
var, omitting braces and semicolons where they are not required, using longer
lines, and so on. However, none of that amounts to significant savings in the
lines of code (it's around additional 30 lines, which I know because the code I
wrote eventually got integrated into a project that uses Prettier and ESLint).
Don't get hung up on such details, ok?
Thing is, this is not the first time. I've also seen a date picker that has 10× the code I needed to implement 90% of its functionality (minus some bad UX I didn't want in mine), for example. And many other examples. At some point, close to a decade ago, I simply stopped using libraries for most things that I can get done within around 1000 lines unless it's related to cryptography or some algorithm, where I'm admittedly somewhat weak.
Code style matters
When I say "coding style", I mean more along the lines of "general approach to coding", not just formatting or paradigm choice. And it does matter, but not just in the way developers usually think it does. That is, they rarely consider the negative impact of coding style choices.
In this particular example, it impacts the amount of code (by a factor of 2, no less!). I've also seen it impact performance by factors of 30. I know that some developers aren't swayed by this type of arguments, but that's really their problem. I see 0 justification for prioritizing code style over payload size or performance when we are talking about such insanely large factors such as 3× code size or 3% of the baseline performance.
Sometimes these differences don't matter. If the original code is 5 lines, it isn't so bad if it grows to 10. But a 230 lines growing to 600 is a serious problem. Imagine how much this grows if you have hundreds of modules like this in your project.
Similarly, a 20 nanosecond function becoming a 600 nanosecond function isn't the end of the world. But a 3 millisecond function becoming 90 millisecond function means you're dropping frames (it means you can't have more than 11 frames per second even if browser took 0ms to repaint and anything else it needs to do between frames).
Perspective
But how come people don't notice this? Surely they must notice such big losses!
The problem is perspective. Rarely do people deliberately write the same non-trivial piece of code in multiple different ways, and especially ways that are aesthetically or otherwise unforgivable to them, just to see if they're, perhaps wrong about something. Or they simply don't work on the kind of problems where these things come in to play (e.g., they don't develop their own widgets). Therefore, they never actually find out they've got an issue.
I'm one of those crazy people that love to challenge themselves to figure out if something can be done differently (even if it's not necessarily better). Sometimes it works, sometimes it doesn't, but when it does, it's accompanied by significant insights and undeniable improvements in how I do things. On my GitHub profile, you won't find two apps that are done the same way because they are both just one-off experiments. The 'app' part is just an excuse to do the experiments for me, not the end goal. 😂
I've also never shied away from reinventing the proverbial wheel just to find out if what people call a 'wheel' is round enough (spoiler: usually they turn out to be pretty square when you put them next to a reasonably round one).
Thanks to this, I know enough different ways to write the same thing to get gut feelings when I see code that's way too big given what it does. Not always, but far more often than I'd like to.
I'm sometimes still surprised at how big of a difference it actually makes, though. I guess it says I haven't experimented enough.
Conclusion
The obvious question remains. How much code are you willing to accept in order to adhere to best practices. And the not so obvious question: how do you even know there's a difference?
