** Summary **

'''TclChecker''' is a fork of [ProCheck%|%procheck], the [Static syntax
analysis%|%static analysis] tool that is included with [Tcl Dev Kit]


** Documentation **

   [http://docs.activestate.com/tdk/5.3/Checker.html%|%official reference] ,version 5.3:   


** Description **

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.


** Additional `.pcx` files for Tcl extensions **

[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].

<<discussion>>Musings
[Peter Lewerin]: I tried TclChecker on some of my longer programs today. I'm not quite sure how I feel about it. TC didn't find very much to complain about, which is 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?

   1. I sometimes omit `--` before the ''string'' argument in a `[switch]` command (TC did '''not''' complain about me omitting the `--` in a `[regexp]` command, however, even when I used a variable dereference for the ''exp'' value.)
   1. I sometimes omit a `default` clause in a `switch` command.
   1. I usually omit the optional ''level'' argument to `[upvar]`.
   1. I occasionally use constructs like `[set] $varName foo`, `[variable] $varName foo`, for instance when initializing a bunch of variables in one action, or `[append] $varName foo` if I need to select which variable to append to.  TC doesn't like any of these, but is satisfied when I change `$varName` to `[[set varName]]`.
   1. TC doesn't realize that variables get initialized by commands like `regexp` or `[dict with]` (OK, that last one is subtle).

(List roughly sorted in order of what I feel is justified to complain about.) 1 and 2: yes, those are valid points, I fixed that immediately and resolved to keep that in mind (even more than I already did) in the future.  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]]`, 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]`, even though I never used OOP.  Namespace ensembles seem to be a mystery to it.

In summary, I suppose it can be really helpful, but it wasn't at this time: it 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.

<<discussion>>

<<categories>> Category Application | Category Dev. Tools