** 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 (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?

   1. I sometimes omit the `default` clause in a `switch` command. Yikes.
   1. I sometimes omit `--` before the ''string'' argument in a `[switch]` command. Oops. (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 usually omit the optional ''level'' argument to `[upvar]`.
   1. I occasionally use constructs like `[set] $varName foo` or `[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. A lot of undefined variables that actually ''were'' defined: TC doesn't seem to realize that variables get set by commands like `regexp`, `[catch]`, 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 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 #1 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 ensemble]s 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 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 at least 
informally, 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.

<<discussion>>

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