in general, annotations on a method are about the method: actual recomendation is ok for that
but JSR 305 annotations are about the return type: IMHO, these annotations are best like proposed by Andreas this would require Checkstyle new feature and consensus in the Maven team to use it let's start with the Checkstyle feature request: I suppose this discussion with Checkstyle dev team will be interesting, to share ideas Regards, Hervé Le dimanche 26 octobre 2014 10:17:13 Dennis Lundberg a écrit : > Hi, > > My personal preference is to have all annotations first, i.e. before the > visibility modifier. > > I checked the JLS, but couldn't find any recommendation. The examples in > chapter 9.7 use the order that Checkstyle suggests. > > -- > Dennis Lundberg > > Den 25 okt 2014 20:38 skrev "Andreas Gudian" <[email protected]>: > > I've started switching on maven-parent 25 in surefire now and I see > > literary hundreds of checkstyle errors (I ignore the warnings for now). > > Most of the stuff is fine with me and I'm on fixing them for a couple of > > days already. > > > > But there's one thing that struck me and that I'm a bit reluctant to > > change > > - and I'd like your opinion on it. > > > > We have for example this method: > > private @Nonnull List<String> getExcluded() ... > > > > Checkstyle now tells me that the @Nonnull should preceed the private > > > > modifier: > > @Nonnull private List<String> getExcluded() ... > > > > Especially as Java 8 introduced the notion of annotated type declarations > > (as in @Nonnull String myNeverNullVariable; ), I think that this > > particular > > @Nonnull annotation should be right in front of the return type and not > > before the visibility modifier. > > > > The message is thrown by the ModifierOrder check (which does other good > > things) and that one can't be configured to behave differently. > > > > So now I'd have to specifically ignore that warning on each method for > > which we qualify the return type with @Nonnull / @Nullable. > > > > What's you pick on this? Is the form suggested by checkstyle really to be > > preferred? I'd open an issue for them if you also think that it might need > > some tweaking. > > > > Thanks, > > Andreas > > > > 2014-10-14 8:34 GMT+02:00 Hervé BOUTEMY <[email protected]>: > > > Le mardi 14 octobre 2014 09:28:21 Olivier Lamy a écrit : > > > > On 14 October 2014 05:01, Hervé BOUTEMY <[email protected]> wrote: > > > > > 2. if we configured Checkstyle to report an error, this means check > > > > > > should > > > > > > > > fail: if you find that it should not fail, please help improve > > > > > > Checkstyle > > > > > > > > configuration by setting severity to warning only > > > > > > > > /me not a checkstyle expert configuration :-) > > > > > > this makes me remember there is a feature improvement for m-checkstyle-p > > > 2.13 > > > that I should explain: I was not a Checkstyle configuration master and > > > > felt > > > > > like you > > > Than I consistently reported Checkstyle rule name and category in every > > > message and report, and a link to Checkstyle documentation for each rule > > > [1] > > > > > > this gives a good intro to Checkstyle configuration and help a lot when > > > needing > > > to @SuppressWarnings( "checkstyle:name of rule, in lowercase") > > > > > > > /me asking himself if having such hard checkstyle requirement help to > > > > improve user experience. > > > > > > from my perspective, previous feature really improved m-checkstyle-p > > > experience > > > and I know I should submit patches to Checkstyle itself, because I think > > > this > > > could help their users too when using bare-Checkstyle > > > > > > Regards, > > > > > > Hervé > > > > > > > > > [1] > > > http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle.html > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
