Monthly Archives: November 2010

JSLint and Technical Debt

After attending a talk delivered by Milan Adamovsky, I started reading through his blog a bit. One of his more recent posts is on why failing a build based on JSLint is a bad idea. JSLint is a code quality tool for JavaScript that encapsulates one man’s view of how JavaScript should be written. I agree that failing a build is too harsh, but let me humbly suggest an alternative: as part of a nightly build, just collect the number of JSLint violations. Much like its Java equivalents PMD, Checkstyle and FindBugs, it is impractical to have “perfect” code according to JSLint. At least in the Java side of things, the standard isn’t to fail the build based on getting a PMD warning, but to do what Sonar does and simply count these violations every night. Given that JSLint is the best static analysis tool out there for JavaScript, even if it should be used with a grain of salt, just counting the number of violations can be useful in computing the technical debt of a project.

I think that if a team is going to configure their build server to fail based on violations, it should only be indirectly through the technical debt metric. Any controversial violations – things that JSLint thinks are bad which your team might think are ok – can be compensated for in the technical debt metric by having higher unit test code coverage to prove the code works predictably. The point of failing a build is that you want to stop “bad” changes, and while having a couple new JSLint violations is probably not a big deal, having dozens and dozens of violations all located in uncovered code probably is.