Dom works on a codebase which has fallen victim to Greenspun's Tenth Rule. Yes, they've implemented a user customization system that is an "ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
Said Lisp implementation started its life as a Java backend, but over the years got ported into Flash apps, iOS, and most recently the JavaScript front end.
While reviewing some of the tests on the JavaScript parser, Dom found some questionable understanding of JavaScript.
test("Returned objects arguments immutable (a b)", function() {
var result = lispParser("(a b)");
expect(3);
ok(typeof(result) === 'object', "result is an object");
var children = result.arguments;
var newValue = 2;
var firstChild = children[0];
if (children[0] == newValue) {
firstChild = ++newValue;
}
notEqual(result.arguments[0], newValue, "Underlying array was immutable");
equal(result.arguments[0], firstChild, "Underlying array was immutable");
});
lispParser
returns an object that represents the syntax tree. In this example, it returns something like this:
{
"function": "a",
"arguments": [
{
"function": "b",
"arguments": []
}
]
}
So we start by expecting 3
. Which, uh, usually the expect
function starts a series of assertions, like we expect(returnValue).toBe(3)
. Here, we just expect three. Nothing about three, we just expect it.
Fine, we check if it's an object. It should be, so great. Then we check if the first argument in (a b)
is equal to 2
. Um, it isn't, so we don't manipulate firstChild
at all. Then, if the arguments didn't change (which, we haven't changed them), we pass the test and call the arguments immutable.
Clearly, someone didn't understand how references worked. They also didn't understand how lispParser
worked, since the argument is never 2
. They wrote a test they didn't understand for code they didn't understand, but at least the test would always pass.