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 > >
