Reverse Engineering Huge TCL Proc

[Lonnie Davis]

Hello all!

I have inherited a huge poorly commented and documented TCL proc in the order of about 2,000 lines with hundreds of variables and a large number of nested IF statement.  What is the best way to go through a proc and determine how it works?  Asking the developer who wrote it is not an option. 🙂

The same proc is used in multiple laboratory interfaces and sends a vague e-mail telling our lab systems team to check the lab system when a scanned report (MDM message) doesn’t match to a resulted order.  The problem is, our lab team doesn’t know what to look for to determine why a scanned report failed to match a resulted order.  I too am unable to determine what happened due to the convoluted code.

As far as I know, a tool doesn’t exist to step through TCL TPS procs to check the value of each variable as an HL7 message passes through it.

What have others done to essentially reverse engineer a monster TCL proc with no documentation or well commented code?

Topic

[Jeff Dinsmore]

I sometimes run into this even if it’s code I’ve written myself ;o)

The first thing I usually do is to ask “is this still necessary”.  If the answer is “No”, the debugging is easy…

If you don’t know how it works and nobody knows what to do when it finds a “problem”, one might wonder as to its usefulness.

If I then decide it’s something we still need,  I’ll frequently step through commands in a hcitcl shell.

You can copy/past a sample message into the shell, then step through commands that act on it.

Alternatively, I’ll use comments (puts) to list values of variables and to trace locations in the code – something like:

puts “thisVar= $thisVar”

or

puts “Top of xyz foreach loop”

Then, run it through the TPS testing tool with a test message to see what it produces.

If you like, you can post the code here and the rest of us with time/interest can take a peek to see if we can help with some clues.

It would also be useful to have a sample message to play with.

Deciphering badly written, undocumented code can be time consuming and painful.  I don’t envy you that job.

Good luck.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Charlie Bursell]

Do you know what you want it to do?  I usually find it easier to just rewrite it.

Most of the time if someone sends me a proc, the first thing I do is reformat it with proper indentations and spacing so I can read the thing.  Once you reformat it, it is easier to figure it out

[Lonnie Davis]

Thanks for the replies.  I’m on my way to getting it sorted out.  After making this post I found other topics here on discussing what tools developers use to write TCL scripts and thought I would try one called Komodo Edit.  The challenge I am facing with this monster proc is cutting it down into manageable fragments to see what and where variables are changing.  The Komodo Edit program has some TCL support and it can group all of the IF statements and expand and collapse them in the editor.  That has been a big help and makes the code more manageable.

To Charlie…

The point of “reverse engineering” this particular proc is to figure out what it does.  It is something that has been in place problem free for about 12 years and the people who defined the business rules and wrote it have been long gone from our organization.  It’s never an issue until something doesn’t go according to plan for the lab team then they ask the interface team what went wrong.  The functionality/ proc itself works fine and never requires debugging. To figure out what it does exactly and why its there will take “reverse engineering” the code as well as having a talk with two different teams to figure out the why.

To Jeff…

I think I will spare the Clovertech community from looking at this proc.  Besides, it checks for so many different conditions I couldn’t even provide an example message for each one!  Thanks for the offer though!

In conclusion, I am still interested to learn how developers tackle tasks like these and what tools are used.  Thanks for the input so far!

[Jeff Dinsmore]

The only way I know, short of retrieving the original author,  is to do what you’re doing – break it down into small enough chunks and slog through.

Komodo is an excellent choice – I didn’t really consider that you may not have a syntax-aware editor.  That’s a great asset for all the reasons you mentioned.

As Charlie advised, definitely take the time to clean up the code and get your indentations straight.  And add lots of comments.  Your successor will thank you.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Steve Williams]

Lonnie,

  As others have said, you’ll have to slog through it; hopefully commenting the code as you go.

FWIW, I use Notepad++ for coding and reverse engineering scripts of all sorts (TCL, ksh, etc). The trick NP++ provides that I do not find in other editors is word tagging/highlighting. I can tag a variable or any other word (like $logfile or myprocOfDoom, whatever) and have every instance of the tagged word in the script light up like a christmas tree. NP++ can track 7 tags at once. I don’t know if Komodo does this trick, but it is a real time saver. Both Komodo and NP++ support code folding, as you have already discovered. Send me a PM if you want more info or screenshots of NP++ in action. Oh, did I mention NP++ is free.  😀

[Charlie Bursell]

Good luck with it Lonnie.  Namespaces are your friend!  Modulize the code

[Author]

Replies