Yeah, besides SonarQube, it looks like each of those TCL tools has limitations in the context of OpenACS. I think Gustaf smartly writes code to detect known problem patterns and edit code. How else can one maintain such a large code base?
My guess is, one can write snippets that focus on various parts of the code base, to identify patterns, make changes etc. or perhaps make large parts of existing code redundant.
I'm not qualified to analyze or suggest acs core changes. Yet, as a package developer, it's clear that this mature framework has some rigidity that I can avoid at will.
For example, right now I notice that db_dml seems clumsy in that every update/create has to be manually generated. Most of the tables I code have essentially the same 20+ lines that vary only by the table name and table elements. So a proc could replace all this replication: a [db_dml_update table_name] where the proc gets the element names, builds the sql and submits to db_dml; But submitting dynamically built sql to db_dml is not recommended. The way around this seems to suggest having to build a revised db_dml that accepts an extra parameter -table. If the revision is accepted into tcl core, then a proc could be written to detect these cases and revise them.. And yet..
There is NextScripting. Maybe this kind of pattern is already addressed in NextScripting. I would suspect so. And so learning and coding NextScripting becomes a way to regenerate a system from within. And then, maybe something like http://wiki.tcl.tk/2131 (XOtclide) but built inside NextScripting becomes part of an evolving solution.
And back to your question, Maurizio:
Is there anyone willing to put energy and time in checking OpenACS TCL code and publishing the results?
What does this entail exactly? Producing useful statistics? creating a proc spell checker and 80 column auto indenter to suggest changes?
