Agreed, how about a section like so: Variable Mutability As a general norm, parameters and variables should be treated as immutable and not be re-used. Where possible, variables that are mutated within a loop should be declared in the loop guard or body. Sometimes it is necessary for clarity to declare mutable variables outside of these contexts, but these should be scoped to the narrowest reasonable code block, with explicit code blocks utilised as necessary for clarity.
As a result of this norm, use of the final keyword within a method body is prohibited. We could instead say “discouraged”, but I am not aware of any context where it is helpful today. From: Marcus Eriksson <marc...@apache.org> Date: Monday, 14 March 2022 at 12:00 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: Updating our Code Contribution/Style Guide Looks good One thing that might be missing is direction on if we should avoid making method parameters and local variables `final` - this is inconsistent over the code base, but I'd prefer not having them. If the method is large enough that we might mistakenly reuse parameters/variables, we should probably refactor the method. /Marcus On Mon, Mar 14, 2022 at 09:41:35AM +0000, 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) > > >
