Re: TR: Is the project interested in the following rules ?

Hi Michael,

First up - thanks for writing about these checks. Do not take my delay 
in responding as lack of interest!

I am curious as to whether you tried using 
http://checkstyle.sourceforge.net/config_imports.html#ImportControl for 
enforcing you layering rules. If so, where was it not suitable that 
required you to write the Package dependencies check?

One of my pet hates in software development is circular dependencies. 
How does your Dependency cycles detection algorithm work and is it 
efficient? That is, how does it scale for large code bases.

Regards,
Oliver

Pawlak Michel (DCTI) wrote:
> 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
>

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/

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