#73 Selective Application of rules

release_3.2
closed
Lars Kühne
5
2012-10-10
2002-05-22
Anonymous
No

I would like to be able to selectively apply different rules to different
project elements.

For example lets consider rules
1. You must use variables matching pattern X
2. You must javadoc all public stuff
3. No unused private members are allowed

I would like to apply (1) all the time.

I would like to use (2) on all public members except;
public static final Strings with name ROLE
Members that match signature A, B or C
(these are framework specific methods which don't need javadoc as
their behaviour is obvious)

I would like to warn about (3) unless it is a constructor in a class that
only contains static members.

Theres a few ways of doing this. One of the more interesting (and
useful IMHO) ways is to always generate warnings but then pass
these warnings to a (chain of) filters supplying enough context
information about where violation occured. It would then be up to the
filter to filter out any audit events it does not want to issue.

Discussion

  • Lars Kühne
    Lars Kühne
    2002-05-23

    Logged In: YES
    user_id=401384

    The chain idea in general is great. The problem with the
    current implementation is that we usually generate error
    messages as we parse the file.

    In other words, in the current implementation of checkstyle
    we usually don't have the full context, whereas in (3) you
    would basically need a representation of the parse tree in
    memory in order to be able to implement the filter for
    typesafe enums.

     
  • Ken Arnold
    Ken Arnold
    2002-07-02

    Logged In: YES
    user_id=66520

    I need something similar, and my thought was less fancy: Most classes should not have public fields, but a few classes simply exist to hold data, for example to allow a method to return multiple values. I was thinking of being able to override variables on a per-class basis: for classes X, Y, and Z allow public members. If this was on a pattern match, it might handle your case.

    This seems to also give a model for someone consciously deciding that certain normally-questionable choices are okay in particular cases; sort of giving permission.

    One way to do this would be to have a property that listed patterns that had special handling. For example, in my case I might want to say:

    -Dcheckstyle.overrides='simpleClass:com.acme.(DataHolder|ReturnStuff) -Dcheckstyle.simpleClass.checkstyle.pattern.publicmember=...
    

    The first property defines that there is a category of identifiers called "simpleClass", and that any class that matches the given regular expression (in this case two specific classes) should prefer the values in the property checkstyle.simpleClass.foo to the value from checkstyle.foo.

    Not sure if this is exactly right, but I think this is in a useful direction.

     
  • Ken Arnold
    Ken Arnold
    2002-07-02

    Logged In: YES
    user_id=66520

    I need something similar, and my thought was less fancy: Most classes should not have public fields, but a few classes simply exist to hold data, for example to allow a method to return multiple values. I was thinking of being able to override variables on a per-class basis: for classes X, Y, and Z allow public members. If this was on a pattern match, it might handle your case.

    This seems to also give a model for someone consciously deciding that certain normally-questionable choices are okay in particular cases; sort of giving permission.

    One way to do this would be to have a property that listed patterns that had special handling. For example, in my case I might want to say:

    -Dcheckstyle.overrides='simpleClass:com.acme.(DataHolder|ReturnStuff) -Dcheckstyle.simpleClass.checkstyle.pattern.publicmember=...
    

    The first property defines that there is a category of identifiers called "simpleClass", and that any class that matches the given regular expression (in this case two specific classes) should prefer the values in the property checkstyle.simpleClass.foo to the value from checkstyle.foo.

    Not sure if this is exactly right, but I think this is in a useful direction.

     
  • Lars Kühne
    Lars Kühne
    2003-01-29

    Logged In: YES
    user_id=401384

    Checkstyle 3.0, which is currently in beta, has two new
    features that are interesting wrt. this feature request.
    - it allows pluggable checks (users can write their own checks).
    - check modules are specified as a tree.

    Hence it should be possible to write a check that acts as a
    Decorator of the original check (haven't tried it, though).
    Such a decorator could for example act as a filter that
    first checks for the ROLE signature before passing the
    visitToken call to the JavaDocVariable module, very similar
    to the original chain idea.

     
  • Oliver Burn
    Oliver Burn
    2003-11-17

    Logged In: YES
    user_id=218824

    The new suppressions feature in 3.2 certainly helps reduce
    the need for this feature.

     
  • Lars Kühne
    Lars Kühne
    2003-11-17

    Logged In: YES
    user_id=401384

    There are now two ways to apply rules selectively (filters
    and decorators), so I think that this RFE is implemented.

    To implement the original chaining idea, we would need the
    AST in the AuditEvent and let filter code check it. I'm not
    convinced that would be a good idea: It doesn't work for
    FileSetSets (no AST), and we for the TreeWalker checks we'd
    have to individually document the position of the AST that
    is provided (e.g. doe it provide the VARIABLE_DECL or the
    IDENT for the ROLE constant).

    Closing this RFE as implemented. If the current filter
    functionality is not sufficient, please file a new RFE (with
    your user name, so we can get back to you).