Being interested in code quality and software engineering practice I have been following (with some relish) the current Javascript tempest in a teapot: “NPM & left-pad: Have We Forgotten How To Program?” (see also here for more discussion).

Image: Ben Halpern @ThePracticalDev

What happened is:

1. A corporate site called NPM decided to remove control of a project called “Kik” from its author and give it to a company that claimed to own the trademark on “Kik.” This isn’t actually how trademark law works or we would see the Coca-Cola Company successfully saying we can’t call certain types of coal “coke” (though it is the sort of world the United States’s “Digital Millennium Copyright Act” assumes).
2. The author of “Kik” decided since he obviously never had true control of the distribution of his modules distributed through NPM he would attempt to remove them (see here). This is the type of issue you worry about when you think about freedoms instead of mere discounts. We are thinking more about at this as we had to recently “re-sign” an arbitrary altered version of Apple’s software license just to run “git status” on our own code.
3. Tons of code broke because it is currently more stylish to include dependencies than to write code.
4. Egg is on a lot of faces when it is revealed one of the modules that is so critical to include is something called “leftpad.”
5. NPM forcibly re-published some modules to try and mitigate the damage.

Everybody is rightly sick of this issue, but let’s pile on and look at the infamous leftpad.

Here is leftpad (copied from the source):

module.exports = leftpad;
function leftpad (str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}

It is going to be a bit long (as it is library code and has to check for more exceptional cases). It appears to be dealing with issues of ch being missing or masquerading as an integer (which I am not sure it gets right- the behavior is may to be pretty nasty if 0 is accidentally passed in instead of '0' for ch). I am sure the author of leftpad is in fact an accomplished and high ability developer, but this one instances just doesn’t look like good code.

But let me show you how padding the word “string” to have total length 10 (by adding 4 zeros) is done in a couple of other languages (one of the reasons authors in these languages would never consider importing something for this purpose).

• Python:

  
  v = 'string'
  '0'*(10-len(v))+v
  

• R:

  
  v <- 'string'
  paste(paste(rep('0',max(0,10-nchar(v))),collapse=''),
     v,sep='')
  

Obviously we can wrap these in a function.

And the Javascript has the classic bit of code that costs you the job during a Google style interview:

 while (++i < len) {
    str = ch + str;
 }

Now I don’t code in Javascript, and I know this doesn’t matter for small len: but this snippet looks bad to the educated eye. Unless there is some clever optimization we don’t know about (such as a compiler visibility analysis replacing the commonly immutable Javascript string with some sort of string builder) the code is inefficient in that it likely takes Omega(len^2) time (often colloquially mis-called O(len^2) time). Now there are some cases where what looks like inefficient code is replaced by efficient code (due to a clever escape analysis, the R language supplies such facilities as we discuss here). But I doubt that is the case here. If it is the case (the code performs differently than it superficially appears), that is important to point out in comments or documentation.

This seems to indicate some users of this code likely never looked at it. So they really had no basis for having a direct opinion as to its quality. I assume Javascript authors use dependencies so much because they are tired from the automatic semi-colon insertion wars (I won’t even link to that).

I can, given a little time, write a reliable efficient string pad function. If one’s argument for including a package for this is that you can not be so trusted, then you really should spend some more time practicing until you can. Nobody can safely navigate a large and changing dependency system reliably over time, so you bring in dependencies when the unavoidable future risk is worth it (such as for reliable date/time classes, databases, and such). Bringing in dependencies because “everybody else does it” isn’t “best practice” it is “cargo cult development.” Yet defending code and practices like the above seems to be a hill a number of people are eager to die on.

I will, also, check if a library I already know and trust brings in a good version of a function I want to use. For example in R I tend to use stringr::str_pad for my string padding. This does bring in a lot of dependencies, but it brings them in all at once and brings in the benefits of trusted faster C++ code.

I am not saying I don’t write bad code (I unfortunately sometimes do), I am saying I find it more productive and less effort to fix such code than to concoct complicated defenses of such code.

It has been our experience that you can find defenders for any bad code or practice under the “its all subjective” rubric. However it is not all subjective, there are actually a few principles of code and development quality which you ignore at your own peril.

Categories: Coding Rants

Tagged as: code quality Javascript

jmount

Data Scientist and trainer at Win Vector LLC. One of the authors of Practical Data Science with R.