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)

Reply via email to