Hi, I was living with the fact that we are putting @Override in the cases you described already. I _think_ it was David Capwell (sorry if I am wrong here) who suggested we should start to put @Override on these methods but it was a very long time ago. I'll try to go over the ML archive to find it. There was definitely a discussion about @Override specifically.
Regards On Fri, 3 Jun 2022 at 15:53, 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
