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
