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