I always ask if we’re ready, get a few acks, then one or two new queries come 
out of the woodwork.

Perhaps I will just publish, and we can start addressing these queries in a 
follow-up process.

From: Dinesh Joshi <djo...@apache.org>
Date: Friday, 3 June 2022 at 16:57
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: [DISCUSS] Change code style guide WRT to @Override in subclasses / 
interface implementations
I don’t think the guide has yet been published to the official website, has it? 
Maybe we should just get it out there.
On Jun 3, 2022, at 8:54 AM, bened...@apache.org wrote:

Somebody hasn’t looked at the new style guide*, the conversation for which 
keeps rolling on and so it never quite gets promoted to the wiki. It says:

Always use @Override annotations when implementing abstract or interface 
methods or overriding a parent method.

* 
https://docs.google.com/document/d/1sjw0crb0clQin2tMgZLt_ob4hYfLJYaU4lRX722htTo


From: Josh McKenzie <jmcken...@apache.org>
Date: Friday, 3 June 2022 at 16:14
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: [DISCUSS] Change code style guide WRT to @Override in subclasses / 
interface implementations
> Avoid redundant @Override annotations when implementing abstract or interface 
> methods.
I'd argue they're not redundant. We're humans and infinitely fallible. :)

+1 to changing this to just always annotate for all the reasons you enumerate.

On Fri, Jun 3, 2022, at 10:16 AM, Alex Petrov wrote:
Right, my thinking matches what David has mentioned:

https://issues.apache.org/jira/browse/CASSANDRA-16096
https://lists.apache.org/thread/mkskwxn921t5bkfmnog032qvnyjk82t7

I'll make sure to update the style guide itself, too, since it looks like there 
was a vote, and intellij file is updated, just need to fixup the website.


On Fri, Jun 3, 2022, at 4:02 PM, Dinesh Joshi 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


Reply via email to