PHPLint - Concepts
PHPLint basic concepts:
- When "php -l" isn't enough. Testing programs is a pain; the
PHP internal syntax validator is certainly useful to detect very basic
mistakes, but it is not enough. "php -l" cannot detect invalid or missing
functions, classes and methods; it does not detect the usage of undefined
variables; it does not detects invalid inheritance rules; it does not
detect invalid path of required sources; it does not detect invalid
namespaces; it does not detect invalid number and type of arguments; it
does not detect missing PHP extensions; it does not detect if DocBlocks
do really match the source code; it does not detect proper handling of
errors and exceptions; it does not detect mixing of incompatible types
in expressions; ...it does not detect pretty nothing because it is not
its task to do that. We need something much more specific. We need
a static validator like PHPLint.
- Rules applied by a static validator should never be relaxed.
Either a source passes the validation, or it does not. Once defined,
rules applies. Then, lets see the main rules:
- Each source file must be validable by its own. All the
PHP extensions it relies on must be listed with the special meta-code
require_module statement; all the PHP source code files it
requires must be listed with the require_once statement or
the class autoloading mechanism should be enabled.
- All is case-sensitive. There may be only one way to write the
name of something, be it the name of a function or the name of a class
or its namespace.
- Each PHP file must be either a program or a library. A library
cannot have verbatim text surrounding the code before the opening marker
<?php and after the ?> closing marker. Moreover,
library files must allow to include them safely without triggering
errors nor checked exceptions in their initialization code, nor they may
interfere with the generated output. PHPLint signals as error including
a file which is not a library in the sense stated above.
- The programmer must always be aware of which and where errors and
exceptions came from. Properly handling errors and exceptions
helps making programs safer and more secure, so PHPLint tracks their
propagation through the code and warns when the program omits to cope
with them.
- Checked exceptions and unchecked exceptions are distinct.
Checked exceptions are those the program should be prepared to handle.
Unchecked exceptions are "internal errors" of the program, or system
limitations the applications should not care about in normal situations.
- Variables have a type that cannot change at run time. The
type of each variable can be explicitly specified or it is guessed
by its usage. The type of a variable, once detected, cannot change:
if $i is intended to store an integer number, only integer numbers can
be assigned to it and that variable can be involved only inside integer
expressions. Usual relaxing rules applies: integer can be assigned to
float; objects of a derived class can be assigned to a variable of a
base class.
- Functions and methods have a signature and must be used
accordingly. The signature includes: the number and type of its
arguments; the type of the returned value; the errors it may trigger;
the checked exceptions it may throw. It is an error invoking a function
or method with the wrong number and type of arguments; the returned value
must be used according to its type; it is an error omitting to handle the
errors and the checked exceptions the function or method could raise.
- The elements of an array must be all of the same type. The
type of the elements of an array should always be explicitly defined,
and these elements must then be used accordingly. Using arrays as generic
containers of data (a very common practice among the PHP programmers)
makes programs hard to understand, impossible to statically validate,
and it is discouraged by the strict typing rules PHPLint applies.
When different types are involved, specific utility classes should be
introduced instead.
- Everything must be defined before being used. You cannot
invoke a function or use a class or a variable if that item is unknown
at the time of the validation. So the rule is: declaration first,
usage next.
- All the properties of a class must be declared. Dynamically
defined properties are not supported by PHPLint (and never will be).
By this rule alone, 99% of the PHP tools out there CANNOT BE VALIDATED
BY PHPLINT. These cases should be avoided or proper utility classes,
interfaces and objects should be introduced.
- Variable-variables $$v, variable-functions $$func and
variable-classes "new $myclass()" are not supported. Along with the
rule above, this excludes the remaining 1%... ;-)
- ...but still the PHPLint Standard Library is fully validable!
Still no comments to this page. Use the Comments link above to add your contribute.
