+1, let's do that.

Kind Regards,
Brandon

On Fri, Jun 3, 2022 at 11:05 AM bened...@apache.org <bened...@apache.org> wrote:
>
> 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