

Yacas has some tools to assess the quality of the scripts.
The code checking tools are never finished, as new bugs
are found, and guards against them added.


The idea behind the static code checkers is to check that
coding standards are upheld, and to mark code that is dangerous 
and thus is likely to be buggy.

The following sections each describe one specific type of test.
The static code analysis code can be found in {codecheck.rep} .

	    Interface check

As described in an essay elsewhere, files should be careful with
what they expose to the environment. the {def} file mechanism
and the {LocalSymbols} routine should be used for this. The
{interface} check verifies that no global resources are accidentally

The rules that should be upheld are:

*	0. global variables should not be accessible to the outside
world. They should be made local to the module by using {LocalSymbols}.
*	0. functions can be global, exposed to the outside world, 
iff they are declared in the corresponding {def} file. Otherwise,
they should be made local to the module with {LocalSymbols}.
*	0. files should not be loaded with {Load} or {Use},
explicitly. Rather, the module should depend on the system automatically
loading the right file through the {def} file mechanism.
*	0. scripts in the standard library should just contain simple
function definitions, transformation rules, and initializations of 
global variables local to that module. 

The {interface} check also assumes the code to consist of simple
function definitions. It is meant to be used for the scripts in the 
standard scripts library. Exposing functionality to the outside
world is usually less of a problem in one-off scripts to do 
specific calculations, for instance.


	    General rules

The following rules are general guide lines.

*	0. the static code analyzer should be able to recognize,
when possible, if variables or functions are defined but not used.
*	0. functions or variables that are not declared anywhere
should be reported, as it might be a typing error. Yacas evaluation just
skips the function call, or lets the variable evaluate to itself.
*	0. platform-specific code is not allowed, in general, and thus
use of SystemCall or PlatformOS or related variables or functions
should be reported.
*	0. macro-like functions with local variables, which use 
{Eval}, or {Map} or related functions that re-evaluate an expression,
should be flagged if the variables are not made unique through 
{LocalSymbols}.
*	0. the tools could discover if a variable is masked by another
local variable with the same name.

	    Transformation rule checks

*	0. ideally there should be a way to determine that type
changes are made. For instance, { 0*{a,b,c} } should return
a list, { {0,0,0} }, and not zero.
*	0. rules that are completely masked by other rules, and
can never be reached, should be flagged.
*	0. rules with the same precedence, but which are ambiguous,
should be reported, as the order in which they are tried might have
impact on the result of application of the transformation rules.
*	0. some form of type checking might be possible, by declaring
input types of various functions, and then examining the surrounding
code to detect when incorrect types might be passed in. It seems to happen
a lot that functions don't verify their input.


	    Coverage checks

Next to checking if functions are declared in the associated
{def} file, the analyzer could also detect if:

*	0. there is no test code for the function
*	0. there is no or incorrect documentation for the function

