On 21 April 2011 11:59, Emmanuel Bourg <ebo...@apache.org> wrote: > Le 21/04/2011 10:21, Simone Tripodi a écrit : > >> - @deprecated in the javadoc is for human readability, @Deprecated is >> for the compiler; > > The compiler is fine with the javadoc tag, and the annotation doesn't > provide a useful comment to the user explaining why it's deprecated and what > to use instead. That's why I don't use this annotation.
Depends on the compiler target. If you target 1.5 or later, then @Deprecated and @Override should be used. > >> - @Override: I suggest you this reply on StackOverflow >> http://s.apache.org/q5s where justified the use of @Override > > The scenario described is not going to happen here. It's impossible to > change the signature of a method in a super class and forgetting to change > the subclasses without breaking a bunch of tests. In the end this annotation > just adds useless noise. Not useless - the intention is to prevent accidental override or failure to override. > >> - final: I would add also immutable fields > > Some fields might be immutable today but variable tomorrow. Why limiting the > options for the future now? There is no harm letting the fields as non final > and changing them later if necessary. That may break binary compatibility. It's better to start with minimum visibility and minimum mutability and relax as necessary, as that is generally binary compatible. Reducing visibility or mutability is generally not binary compat. Final fields are useful in helping to ensure thread-safety, but CLI is not the sort of library that really needs thread-safety, and making it thread-safe may require a total rew-write. Final fields also make debugging and testing easier, as there are fewer states to test. > On the other hand, you are going to > hesitate and ponder if the sky isn't going to fall if you have to remove a > final modifier later that was added without a very good reason. Removing a final modifier is less likely to cause binary compat. issues. > Emmanuel Bourg > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
