Refactoring for the Holidays

In years past I’ve gotten ready for Christmas Eve and Christmas Day by getting the coding portion done during free moments earlier in the day, so that when the evening came all that was left was to write the development log. This year I’ve been too busy for that, and so I have to do all of my coding in the evenings, which during these last couple of days has been at a premium.

I did get some visible coding work done, though; you can’t keep an old coder down.

The brunt of the changes made today were in refactoring most of the linting code that was previously written. The initial command performs only a single lint operation (telling you about links that don’t exist in the index), but there are more checks to be done to ensure that everything will work as expected, as well as pinpointing areas that need more work.

This first stage was in pulling the common code out of the command and into helper routines, because there’s no need for that command to be crufted up with so many specifics. The resulting command is a lot smaller now, utilizing the new utility routines to do most of it’s work so that the only method it has of any substance at this point is for performing the actual lint.

The rest of my time was spent trying to work up a good framework for what should come next, which is to implement lint rules as a collection of classes that know how to perform a lint operation on either a single file or on a help project as a whole. Once that’s done, the linter will be able to either determine what lints it should perform based on the input or possibly also from command arguments.

There is no code for this yet since my design spit balling is not really something that needs to be in the code until it’s finalized, since I’m a large believer in not checking in non-working code.

The ultimate goal is to have the available lints classified in two types, one that applies to single help files and one that applies to all help files as a whole. The lint command can then pick and choose from the list based on the criteria of the type of file that it was told to lint (index or single help file) as well as command line arguments. It would then execute the lints one after the other in each file, collecting the results for final display.

With the lints abstracted away into classes and the command using helper methods, this means that new lints can easily be added without having to actually touch the command at all. It would also allow some optimization, such as letting group lint commands have a pass where they collect required information from all files one at a time, and the ultimately collate it at the end instead of each command iterating all files.

I’m going to ruminate on the way I’d like to go about this a little bit more tomorrow to make sure that I don’t head down the wrong path and have to rip code apart later.