https://lists.apache.org/thread/mkskwxn921t5bkfmnog032qvnyjk82t7
On Fri, 3 Jun 2022 at 16:11, Derek Chen-Becker <de...@chen-becker.org> wrote: > > I think we discussed this a couple of weeks ago, but to reiterate my > position: I think we should use annotations where they allow the compiler and > ancillary tooling (e.g. FindBugs) to catch and prevent classes of errors. > @Override seems like a pretty easy one to add, and has concrete examples of > the kinds of errors it can prevent. We discussed @Nullable, @Threadsafe and > others that may have more marginal utility, so we were a bit less > prescriptive there. To sum up, I agree with Alex that @Override has enough > utility to say we should use it by default. > > Cheers, > > Derek > > On Fri, Jun 3, 2022 at 8:04 AM Dinesh Joshi <djo...@apache.org> wrote: >> >> So your proposal is to always add override annotation? Or are there >> situations where you don’t want to add them? >> >> >> On Jun 3, 2022, at 6:53 AM, Alex Petrov <al...@coffeenco.de> wrote: >> >> >> Hi everyone, >> >> In our style guide [1], we have a following statement: >> >> > Avoid redundant @Override annotations when implementing abstract or >> > interface methods. >> >> I'd like to suggest we change this. >> >> @Override annotation in subclasses might be annoying when you're writing the >> code for the first time, or reading already familiar code, but when you're >> working on large changes and have complex class hierarchies, or multiple >> overloads for the method, it's easy to overlook methods that were not marked >> as overrides, and leave a wrong method in the code, or misinterpret the call >> chain. >> >> I think @Override annotations are extremely useful and serve their purpose, >> especially when refactoring: I can change the interface, and will not only >> be pointed to all classes that do not implement the new version (which >> compiler will do anyways), but also will be pointed to the classes that, to >> the human eye, may look like they're overriding the method, but in fact they >> do not. >> >> More concrete example: there is an abstract class between the interface and >> a concrete implementation: you change the interface, modify the method in >> the abstract class, but then forget to change the signature in the overriden >> implementation of the concrete class, and get a behaviour from the abstract >> class rather then concrete implementation. >> >> The question is not about taste or code aesthetics, but about making >> maintaining a large codebase that has a lot of complexity and that was >> evolving over many years simpler. If you could provide an example where >> @Override would be counter-productive or overly burdensome, we could compare >> this cost of maintenance with the cost of potential errors. >> >> Thank you, >> --Alex >> >> [1] https://cassandra.apache.org/_/development/code_style.html > > > > -- > +---------------------------------------------------------------+ > | Derek Chen-Becker | > | GPG Key available at https://keybase.io/dchenbecker and | > | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | > | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | > +---------------------------------------------------------------+ >
