On Thu, Apr 21, 2011 at 8:03 AM, sebb <seb...@gmail.com> wrote: > 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. >
+1 Gary > > > > >> - 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 > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
