#525 Support for @Generated annotation

Julien HENRY

@Generated aims at being the standard way to mark generated code [1].

Very often we have to configure checkstyle to ignore generated code as we
don't have any chance to fix it (especially if the generated code is cleaned and regenerated during each build).

I suggest to add an option to checkstyle that would allow to ignore
packages/classes/attributes/methods that are marked with @Generated

Moreover @Generated support a "value" attribute that is used to give the
name of the code generator.

For example I can have in my src folder:

public class MyClassGeneratedByFoo {

public class MyClassGeneratedByBar {

public void methodGeneratedByBar() {

public void methodCustom() {

Say I don't have any control on the Bar code generator output style. On the opposite say I have control on Foo code generator.

So I would like to have a way to tell checkstyle to ignore methodGeneratedByBar
but not MyClassGeneratedByFoo.

For example you can add a String array parameter that would list all generator codes (matching @Generated value) that have to be excluded from the analysis.


[1] http://java.sun.com/javase/6/docs/api/javax/annotation/Generated.html


  • Oliver Burn
    Oliver Burn

    thanks, an interesting idea

  • Dale King
    Dale King

    It would probably be best to have two settings one for ignoring methods and one for ignoring classes and have a parameter for the list of tags to signal ignoring the class/method. By default this parameter could be set to Generated. Might also want to include Test in the default for junit tests.

  • Julien HENRY
    Julien HENRY

    In my organisation, JUnit tests are part of developper work and have to follow code guidelines. For me it seems logical because JUnit tests may have to be maintained for a long time even if this is not (always) code that is delivered to customer.

    So in my case I want to ignore @Generated code (with perhaps some exceptions for code generated by a home-made tool). But I don't want to ignore @Test.

    So I suggest to not put @Test in default exclusion list as it is not encouraging good practices.

  • Dale King
    Dale King

    My point was not what was in the default, but that the tags be configurable and not just add something that only did it for generated. Since it would be configurable you could remove Test if you wanted to.

    This all gets back to an idea I have brought up before. The problem with Checkstyle configuration is that you can declare filters, but they only apply to suppressing output under certain conditions. It still runs the tests. What you really want is to specify conditions for when checks should be run.

    This is an example of that. You want to surpress running checks on these classes. You don't want to have it run the checks and then just ignore the output from running those checks.

    You might want to look at this thread which discusses an idea I proposed for making it more declarative of which checks get run on which files:


  • Dustin Parker
    Dustin Parker

    Any progress on this? I'd be interested in submitting a patch if you have any tips about where to start...

  • Tony Hedoux
    Tony Hedoux

    Any news about this evolution? There is more and more generated code and annotation; these option will be very usefull.

  • Martin Zeltner
    Martin Zeltner

    Is there now a way to handle @Generated?