Software, technology, sysadmin war stories, and more. Feed
Sunday, October 28, 2012

Taking responsibility for lint in your source code

I used to work with a code depot which had a great deal of local customization. It had its own custom build tools and even a meta-Makefile which turned into a Makefile at build time. It had a bunch of utilities which helped people keep a handle on all of this. One of the things it could do was run a "lint" check on the code. It would look for trailing whitespace, badly-indented code, and other things a simple regex type search could find.

An interesting quirk about this tool is that it could tell you what sort of lint issues had been introduced by you in your current working tree, and which ones had been there previously. It looked a little like this:

$ lint_thingy
Linted 9 files; 2 with 1-10 old warnings, 7 with 0 warnings.

In other words, nothing I did this time around introduced any new cruft, but there were 2 files which had some problems in them already when I checked them out. I figured that at this point, people would handle this one of three ways:

A. Say "Awesome! I didn't introduce any new lint!" and mail off the code for a review.

B. Not even notice it at all, since they don't ever use the lint tool.

C. Turn around and ask the lint tool to show the old problems so they might be knocked out at the same time.

I guess there might be a fourth option, too:

D. Make a mental note about the lint. Send in the current patch for review as-is, and once it's checked in, make another sweep through the tree for lint and send in a separate patch for that. This is basically "A" followed by "C".

My guess is that most people were in groups A or B. They were either completely ignorant as to the lint situation, or were able to engage their "SEP field" and only worry about the stuff they caused themselves.

I'd love it if things were to the point where the debate was over whether you should do "C" or "D" -- that is, a discussion about unrelated changes in a patch. Unfortunately, in my experience, it rarely gets to that point.

If you have a bunch of people working in a garden, and someone throws a can into it, who picks it up? I'd think the nearest person who happens to be working at the time would make sense. Sure, it would be great if the person who threw it there could be rounded up and forced to clean up their own mess, but that's not always possible. They might be long gone.

If nobody picks it up, pretty soon your garden will be more cans than plants, and I'm pretty sure nobody wants that, either.

Unless, you know, you really want a can garden. If so, knock yourself out.