Ralph - 2018-05-23

Hello, I like your plugin. But I miss a way to prevent the JavaDoc creation for some fields.
(I did not create an ticket, because: maybe I overlooked something)

What I want to do, is to prevent JavaDoc generation for some fields that are so well known that the do not need any autogenerated documentation, for example:
- private static final long serialVersionUID
- private static final Logger LOGGER = LoggerFactory.getLogger

So I tried several ways to prevent JautoDoc from creation JavaDoc comments for a field with name "serialVersionUID". One was to modify the default field template

#if(${e.g(0).equals("serialVersionUID")})
#else
/**
#if(${e.isStatic()} && ${e.isFinal()})
 * The My Constant ${e}.
#else
 * The ${e.rs()}.
 */
#end
#end

But it does not work, because as soon as the template result is empty, it seams that a fallback is used to generated the comment. (It is likely that this stackoverflow answer descipe the internal challange https://stackoverflow.com/a/33323718/280244)

So I am asking: is there a way to instruct JautoDoc to ignore some fields? Should I create an Feature-Ticket? Is there any way I can help you with that feature?

BTW: I thing the "problem" of avoiding JavaDoc for some fields is bigger than my two simple examples. Background: I think JAutodoc is a great tool to provide some starting point for writing JavaDoc. Because my observation is that: if there is already an JavaDoc comment for an method or fields that it is more likely that a programmer improves it. But if there is no comment for this field/method at all is is less likely.
On the other hand there are some fields/methods that will almost never have a meaningful comment (autogenerated serialVersionUID, logger)... So a autogenerated JavaDoc comment for this methods will always rise an discussion about the usefulness of comments and (because this examples are in most cases really useless) will reduce the acceptance of JavaDoc at all.
So there are some other cases where a JavaDoc comment for an fields is almost not useful: For example in a Spring Application: a Service does often have some fields with references to an Repository (DAO). In this case it is often quite useless to document this fields, because is is just the reference to this Repository.
But the rules to define this fields are more complicated than just an RegEx.

Best Regards
Ralph