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 <mailto: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 > > <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)
