Checking Code in Scripts

[bamakojeff]

I've been wanting to do a series of checks on my code like making sure that all queries are parameterized, database calls are checked for success or failure, etc. I started by searching for every "revDataFromQuery" (for example) in the code and then going to that script and checking it manually, but that's tedious and easy to miss errors. Then Bernd's recent stack to diff scripts inspired me that there was a better way.

So (with a little help from Claude.ai) I worked up a stack to crawl my stack and copy out all the code and then print everything either in one big document or each script in its own file (which will make it a lot easier to move this project to using scripts, which I need to do before it gets even bigger than it is). One big document made it fairly easy to write scripts to check that every call to "revDataFromQuery" was parameterized if possible, was followed by a check for success or failure, etc., etc.

I suspect that this already exists, but as Hubris is a virtue in a programmer, I wrote my own. For anyone who doesn't want to write their own, the script is attached here, and you can also get it on github: https://github.com/claypotfrog/LCScriptInspector

Jeff

[trevix]

Hello.
Thanks for the upload!

Recently I started using Claude AI to debug some part of my pretty big LC standalone. In order to do this I had, every time , to copy and paste LCS on txt files so that Claude, in the OSX Terminal, could read it. A long and boring process.

I think your solution could be of great help and I tested it over my standalone.
I noticed the following:
1. apparently substacks are listed at the same saved path level of the Main stack they belong to
2. nested groups are not listed as such, in the saved path (no folder hierarchy). Solving this, would also make the directory more clear to read
3. object without code are not listed in the saved path (hard for Claude probably to understand the hierachy of objects)
4. In your tests, was Claude understanding correctly your saved structure?

I wonder if you have continued the development of this tool. If not, why?
Before I start the long process of understanding your tool in order to improve it, it would be useful to know your opinion on the above.

But anyway, thanks so much for your work.
Trevix

[bamakojeff]

Dear Trevix,

I'm glad the stack was useful to you. You are right about its limitations. I wrote it to create the One Big File of all the code that I could feed that into Claude for analysis. Saving the scripts separately either in a flat file or directory structure was an afterthought (and it shows). It does what I wanted it to do, so I've not done any more development on it except the issue below.

One problem with writing out the scripts separately is that if you have objects of the same name in different groups on the same card, they overwrite each other. I have a few "cancelBtn" buttons in different groups on the same page, and each one overwrote the previous. So I have a new version of the stack which adds an "owner" to each name to avoid the collisions. I looked and saw that I never uploaded that to the Github page, so I just put it up. But it really doesn't change anything in the One Big File except to add an "OWNER: ..." to each the header.

I found that Claude was able to read the structure of the code that this tool created with no problems. I was able to ask it questions of the code and it had no issues working through it and giving me good answers.

HTH

Jeff

[bwmilby]

I've got two projects that may be useful in this context. The first (older) is ScriptTracker that just exports scripts of a stack as files:
https://github.com/bwmilby/scriptTracker
It does leave artifacts in the stack that it processes (a custom property set is added to each object with a script). One of the keys is binary and I've had at least one person say that it caused issues for them (although I've not had any).

The second isn't posted as an individual project yet, but you can see its output here:
https://github.com/Milby-Computer/hxt-bst
That is an export of all of the binary stacks in the HyperXTalk repository. It is probably a good place to see how it handles stacks and their scripts. It is still a work in progress though - so feedback is welcome. Currently I run it over a directory and it just processes everything. It does leave a hash of the stack in the folder structure so it can know if there have been no changes (as opposed to putting it in the stack itself for each script). Scripts have a header added and include an encoded hash. (bst.hyperxtalk is the actual stack and it should work fine in LiveCode and openXTalk).
In both projects the scripts are flat (in a single folder) so it would be easy to watch the folder to detect changes to allow editing outside of the IDE and have the IDE import the code automatically (implemented in ScriptTracker but not in BST).

For your tool, I'd suggest that you run it on your own tool and add the output to the repo. Then every time you make a change the updates made will be evident. I've done this for ScriptTracker and plan on doing that when I make a repo for BST.

[SWEdeAndy]

@bamakojeff:
Related to getting an overview of your scripts, you might also find use in the ScriptDependencies tool
(https://github.com/wheninspace/WIS_ScriptDependencies) that gives a complementary/alternative perspective of your code. The flowcharts it generates are often quite interesting, sometimes mindblowing.

[trevix]

@SWEdeAndy
I tested your WIS_ScriptDependencies tool on my pretty big standalone. Very fast and, I guess, useful.
I'm saying this because the report was so big that I wouldn't know what to do with it.

Sorry if I am wrong, but I would expect this tool to report broken dependencies.
Was it made for this and I don't know where to look at, or is it just a tool to examine the dependencies?
Anyway, thanks for your upload.
Trevix