Forum OpenACS Development: wiki code metrics for packages, add standards metrics?

the more general coding guidelines page is [1]. Several of the mentioned code metrics are implemented since many years on the OpenACS web site for all packages (see e.g. [2]). Of course, more metrics can be added. Much of the work invested into OpenACS over the last three years went into improving code quality, such as removing obsolete idioms, deprecated functions, dead code, unused .xql statements, security concerns, obsolete coding practices, etc. This affects and Tcl/HTML/SQL (e.g. in much of the PostgreSQL code was developed having pg7 or earlier in mind). I was in many place reluctant with code reformatting according to the guidelines, since such a change makes it quite hard for installations with locally modified code to merge the code. Furthermore, several of the quality measures above are hard to quantify.

I am not sure, how many people look a t the code metrics, but it can be certainly improved. There are as well several "code smell detectors" in automated testing (e.g. checking naming conventions, comments, etc.). I am not sure, how many people are actively using automated testing. Improving this is as well worthwhile.

Anyhow, it is certainly possible to add various code metrics to e.g. the package manager (e.g. before making e.g. an .apm file) or the the OpenACS site. Contributions are always welcome.

-g

[1] https://openacs.org/xowiki/coding-standards-index
[2] https://openacs.org/xowiki/acs-subsite

For Naviserver (C/C++) please have a look at:
http://sonarsrv.spazioit.com/overview?id=42350

For OpenACS (pure Web/Html, no TCL) have a look at:
http://sonarsrv.spazioit.com/overview?id=myOpenACS

For general information about the topic of Quality Platforms, Code Analysis, Metrics and the like, please have a look at:
http://www.spazioit.com/pages_en/sol_inf_en/code_quality_en/

Hope this helps,
Maurizio

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?

Html in adp pages are not so simple to analyze. Wonderful work has gone into upgrading html/css partly by invoking per page html analysis at time of rendering. You can see this in the latest OpenACS release 5.9.

To me, at least 80% of that documentation should be removed, because it no longer fits the code, or is off topic etc. Some of it should be put directly in the code at the points of discussion to provide needed context, even if it is just historical. The remaining 20% should be integrated into the wiki.

As for Tcl testing, when I write a linter for my own code, then we'll see if it is applicable for acs-core --I think not. Because I write code as if I just learned the language. Much of acs-core uses syntax and terms I have little experience with.

I see that SonarQube has a ruleset for Python. Maybe that can be adjusted for Tcl with your experience and knowledge of naviserver?

cheers,
Ben

As for me, I need to finish what I have started already. I will cheerfully suffer through my commitments knowing that there is something even more fun to do.