Oh, I certainly don't mean to block the purposed update. I'm sorry if it
sounded that way. All I'm saying is we should add Python code style
guides to it, and a follow up addendum can surely do the job.
On 14/03/2022 11:41, Josh McKenzie wrote:
+1 to the doc as written. A good portion of it also applies to python
code style (structure, clarity in naming, etc).
Perhaps a python specific addendum as a follow up might make sense Bowen?
On Mon, Mar 14, 2022, at 7:21 AM, bened...@apache.org wrote:
I think the community would be happy to introduce a python style
guide, but I am not well placed to do so, having chosen throughout my
career to limit my exposure to python. Probably a parallel effort
would be best - perhaps you could work with Stefan and others to
produce such a proposal?
*From: *Bowen Song <bo...@bso.ng>
*Date: *Monday, 14 March 2022 at 10:53
*To: *dev@cassandra.apache.org <dev@cassandra.apache.org>
*Subject: *Re: Updating our Code Contribution/Style Guide
I found there's no mentioning of Python code style at all. If we are
going to update the style guide, can this be addressed too?
FYI, a quick "flake8" style check shows many existing issues in the
Python code, including libraries imported but unused, redefinition of
unused imports and invalid escape sequence in strings.
On 14/03/2022 09:41, 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:
1. Deemphasis of getX() nomenclature, in favour of richer set of
prefixes and more succinct simple x() to retrieve where clear
2. Avoid implementing methods, incl. equals(), hashCode() and
toString(), unless actually used
3. Modified new-line rules for multi-line function calls
4. External dependency rules (require DISCUSS thread before
introducing)