TclChecker is a fork of procheck, the static analysis tool that is included with Tcl Dev Kit
TclChecker covers the extended commands of Tcl 8.4 and 8.5, fixes bugs in the checking for other versions, adds checks for new possible errors, and was also integrated with tcldebugger and the Komodo IDE.
LV: So, has anyone created the necessary .pcx files to allow tclchecker to check the more common tcl extensions? TDK comes with some documentation on creating these files. However, they are relatively complex. It would be useful to try and take the info from the doc and try to write a usable .pcx file, just to work out the kinks of how things work. It seems pretty complex.
AK: I have .pcx files for some of the packages in Tcllib. I will commit them (incrementally) to Tcllib. They will require version 4.1 of Tcl Dev Kit.
Musings (a kind of review)Peter Lewerin: I tried TclChecker on some of my longer programs today (2014-01-11). I'm not quite sure how I feel about it. TC didn't find very much to complain about, which I suppose could be because I'm just that good -- OTOH, it could mean that TC fails to detect anything beyond the most obvious blunders. So, what did it find?
(List roughly sorted in order of what I feel is justified to complain about.) 1 and 2: yes, those are valid points, I fixed those cases immediately and resolved to keep that in mind (even more than I already did) in the future (I was taught not to do #2 in the early 1980s, and have taught students of my own not to do it: I don't know why I still miss this sometimes). 3: Um, OK, maybe that's valid, even though I can't see myself passing in a variable name starting with a digit or a hash sign. 4: What's the problem, really? (Sure, sometimes it is a bug-causing mistake, and a serious one at that, but it wasn't in any of these cases.) I did make the change to [set varName] while negotiating with TC, but I don't think I'll change my ways in the future. 5: This is TC's problem, not mine. Unfortunately, short of inserting an excluding pragma or a set command there doesn't seem to be a way to arrange the source to avoid this false positive. I mean, if a variable really is undefined at the point of use, I will notice it not by running a checker, but by the program, you know, crashing.
Also, even though I specified version 8.6, TC didn't recognize the lmap command. Neither did it know about cmdline. It did check oo for some reason (I wasn't using OOP). Namespace ensembles seem to be a mystery to it.
I think I will test TC once more while actually creating a program (as opposed to trying it on working, more-or-less error-free programs). Maybe it will prove more useful in that situation.
In summary: if I were the manager of a team of programmers I'd insist on everyone using TC before checking in code because it would be a good practice (a work environment is no place for idiosyncrasies or code that is even remotely dubious). For myself as a hobby programmer, I'm good if the program runs correctly (and I do test them, out of habit). While I suppose TC can sometimes be really helpful, it wasn't at this time: it mostly came dangerously close to just being a bother. I don't think I'm going to spend the money to get the license for it.