I agree with the single commit approach to fix it all. TBH Javadocs are a little bit messy as well, warnings on generating them, incomplete, in a lot of cases obsolete or they do not reflect the code anymore etc.
On Tue, 15 Mar 2022 at 09:44, bened...@apache.org <bened...@apache.org> wrote: > > I’d be fine with that, though I think if we want to start enforcing imports > we probably want to mass correct them first. It’s not like other style > requirements in that there should not be unintended consequences. A single > (huge) commit to standardise the orders and introduce a build-time check > would be fine IMO. > > > > I also don’t really think it is that important. > > > > From: Jacek Lewandowski <lewandowski.ja...@gmail.com> > Date: Tuesday, 15 March 2022 at 05:18 > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > Subject: Re: Updating our Code Contribution/Style Guide > > I do think that we should at least enforce the import order. What is now is a > complete mess and causes a lot of conflicts during rebasing / merging. > Perhaps we could start enforcing such rules only on modified files, this way > we could gradually go towards consistency... wdyt? > > > - - -- --- ----- -------- ------------- > Jacek Lewandowski > > > > > > On Tue, Mar 15, 2022 at 1:52 AM Dinesh Joshi <djo...@apache.org> wrote: > > Benedict, I agree. We should not be rigid about applying any style. > stylechecks are meant to bring uniformity in the codebase. I assure you what > I am proposing is neither rigid nor curbs the ability to apply the rules > flexibly. > > > > On Mar 14, 2022, at 4:52 PM, bened...@apache.org wrote: > > > > I’m a strong -1 on strictly enforcing any style guide. It is there to help > shape contributions, review feedback and responding to said feedback. It can > also be used to setup IntelliJ’s code formatter to configure default > behaviours. > > > > It is not meant to be turned into a linter. Plenty of the rules are stated in > a flexible manner, so as to permit breaches where overall legibility and > aesthetics are improved. > > > > > > From: Dinesh Joshi <djo...@apache.org> > Date: Monday, 14 March 2022 at 23:44 > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > Subject: Re: Updating our Code Contribution/Style Guide > > I am also in favor of updating the style guide. We should ideally have custom > checkstyle configuration that can ensure adherence to the style guide. > > > > I also don't think this is a contended topic. We want to explicitly codify > our current practices so new contributors have an easier time writing code. > > > > It is also important to note that the current codebase is not consistent > since it was written over a long period of time so it tends to confuse folks > who are working in different parts of the codebase. So this style guide would > be very helpful. > > > > On Mar 14, 2022, at 2:41 AM, bened...@apache.org wrote: > > > > Our style guide hasn’t been updated in about a decade, and I think it is > overdue some improvements that address some shortcomings as well as modern > facilities such as streams and lambdas. > > > > Most of this was put together for an effort Dinesh started a few years ago, > but has languished since, in part because the project has always seemed to > have other priorities. I figure there’s never a good time to raise a > contended topic, so here is my suggested update to contributor guidelines: > > > > https://docs.google.com/document/d/1sjw0crb0clQin2tMgZLt_ob4hYfLJYaU4lRX722htTo > > > > Many of these suggestions codify norms already widely employed, sometimes in > spite of the style guide, but some likely remain contentious. Some > potentially contentious things to draw your attention to: > > > > Deemphasis of getX() nomenclature, in favour of richer set of prefixes and > more succinct simple x() to retrieve where clear > Avoid implementing methods, incl. equals(), hashCode() and toString(), unless > actually used > Modified new-line rules for multi-line function calls > External dependency rules (require DISCUSS thread before introducing) > >
