I’ve opened a PR: https://github.com/apache/cassandra-website/pull/137
Not sure what our commit norms are for the website, but I’m assuming we would normally expect a +1 from somebody else. From: Dinesh Joshi <djo...@apache.org> Date: Saturday, 4 June 2022 at 19:59 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Change code style guide WRT to @Override in subclasses / interface implementations sounds good. Lazy consensus it is. On Jun 4, 2022, at 11:09 AM, bened...@apache.org wrote: I think lazy consensus is good enough here, since there has been no dissent so far as I can tell. It’s easier to modify if we assume lazy consensus until a dispute arises. If anyone wants to escalate to a formal vote, feel free to say so. I’ll update the wiki in a couple of days; we can always roll back if a dissenting voice appears. From: Dinesh Joshi <djo...@apache.org> Date: Friday, 3 June 2022 at 18:34 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Change code style guide WRT to @Override in subclasses / interface implementations Let’s bring it to vote? We can update the docs as we evolve the guidance but I think it’s in a good enough shape to publish. On Jun 3, 2022, at 9:07 AM, 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
