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