TR: Is the project interested in the following rules ?

Hello,

In the scope of the development of a quality platform project, we are
implementing some checkstyle 4.4 checks to verify the rules of our
development / architecture standards. Now I'm writing the following
email to the list in order to ask if the checkstyle project would be
interested in them. 

One of the main feature of these checks is that they are completely
configurable and generic. Indeed, we wanted to have adaptable checks
allowing us to make evolve our quality standards without having to
redevelop the checks, and we also wanted to enable anybody to adapt them
to their precise needs without having to follow our own standards. By
"anybody" we meant the checkstyle users community ;-)

Here follows a description of the checks :

===
1. Type names verification

We use this check to verify that types respect the naming standard which
are in place. For instance we want that all Exceptions end with
"Exception", all interfaces end with "Able", all formbeans start with
"Fb", etc. Instead of writing a check for each rule, we wrote a single
check that can be configured as follows :

a. must the rule be applied to interfaces or to classes ?
b. must the verification occur only if the type is an instance of a
given base type (for instance only to subclasses of
"java.lang.Exception") or must it be always applied (for instance it
must be applied to all interfaces)
c. what is the text that must be be present (for instance "Able",
"Exception")
d. where must it be present (prefix or suffix) ?

===
2. Package root 

We use this simple check to verify that all projects use a correct
package root. (for instance, in our organization, all packages must
start with "ch.ge." and packages names should include information about
the department and project they are part of. Thus, packages part of
project "b" of department "a", should be prefixed "ch.ge.a.b.")

===
3. Package dependencies - In a context where we use package names to
represent architecture layers, we needed a rule allowing us to define
what package dependencies (calls from package A to package B) are
forbidden. We develped thus a check enabling us to check that each layer
is correctly isolated from other layers. 

In this check, all dependencies are described using regular expressions,
which allows us to extend the verification at will (for instance to add
new layers, or to adapt the check to projects having used another naming
scheme for layers (for legacy projects for instance)).

To give you an idea of what we can do with this rule, as attachement you
can find an example of verifications we are currently doing. This shows
what the check allows us to verify and what we currently cannot verify.
Plea <<checks.pdf>> se note that all these verifications are done by
instanciating the generic rule only 5 times.
 
The rule can be configured as follows :
a. the package to which the rule must be applied (the layer to be
verified) as a regexp 
b. the imports that are forbidden as a regexp
c. a switch to ignore the rule if the checked type is already in a
"forbidden" package (this allows us to have rules that say that "no
class can import a class from package B or its subpackages, unless the
class is from package B or its subpackages"

==
4. Dependency cycles detection - This check aims at detecting dependency
cycles between components. Such cycles are difficult to detect by hand
and impede the maintainablity and evolvability of the code. To represent
components we use regular expressions on packages.

Currently, the check simply outputs cycles as logs "component A ->
component B -> component C -> component A" (for instance). In the
future, I plan to improve it to provide more information to help break
these cycles. Two parameters are available : 
a. the regexp allowing to detect components (for instance, if a package
has a subpackage named "api" then it is a component)
b. the regexp specifying the packages which have to be scanned for
cycles (for instance if we want to scan only a given set of components)

If you need any more information feel free to ask :-)

Best regards,

Michel Pawlak

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Checkstyle-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/checkstyle-user