Test Double has been successfully specializing in JavaScript for more than two years, which is unusual for a boutique consultancy. It was from this position that I was preparing a talk with our best practices. I was atop my favorite mountain with two brand new stone tablets, chisel in hand, ready to drop some wisdom up in here.
I hesitated. The advice I was preparing to give was advice I wasn't sure that I believed. Yes we're very good at building systems with JavaScript, but am I certain of which practices are actually beneficial vs the ones that might just be dogma?
This blog post contains the framework I used to examine our practices, for I feel that the framework is more interesting than the answers I derived.
Code serves three masters. The machine, the maintainer, and the user. I want to focus on shipping code for the user while keeping it as maintainable as possible. For the machine, it must execute, but I will ignore performance concerns until they are proven to be a problem. I'm ignoring the needs of the machine past the ability to execute.
“I think we’re in trouble. I don’t think we have the foggiest idea how to compute very well.” - Dr Gerald Sussman
Hypothesis - More understandable when put in terms of managing dependencies. What this code needs in order to run.
The only means of communicating the implementation details of code is through executable code. Since code is the specification for code we must hold it to the same standards as natural languages. Yet it must also execute.
Will's code is still pretty readable. I doubt mine will be so readable in 400 years. Mostly not my fault. Web development is rapidly evolving the idioms are changing as quickly as the languages and the libraries. There is a culture shift; JavaScript and Ruby from 2009 look positively archaic.
The readability is unknown until the reading happens. But we can make bets.
Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all sentences short or avoid all detail and treat subjects only in outline, but that every word tell. - William Strunk JR.
Readability has little to nothing to do with names, nor must it emulate natural language structure. But code must tell.
Hidden Code
Flexibility because systems under use never stop changing. Readability because writing code is the inexpensive part. Readability and flexibility are not absolutes, nor can we say with any certainty