he.org
Subject: Re: Updating our Code Contribution/Style Guide
On Mon, 30 May 2022 at 22:37, Ekaterina Dimitrova
mailto:e.dimitr...@gmail.com>> wrote:
I also like it, thank you for putting it together. We can always add more and
more, but I think the current one is already quite exten
On Mon, 30 May 2022 at 22:37, Ekaterina Dimitrova
wrote:
> I also like it, thank you for putting it together. We can always add more
> and more, but I think the current one is already quite extensive. I like
> the dependency management point.
>
The dependency management paragraph, no objection
Miklosovic
Date: Tuesday, 31 May 2022 at 14:20
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
Hi Benedict, all,
I do not want to hijack this thread, if we want to have separate
discussion about that I can open one but anyway ...
What do you think about
some linters? This
> might be a good thing, if we are willing to be liberal with @SupressWarnings.
> I’m not sure how we would transition, though, with so many existing warnings.
>
>
>
>
>
>
>
> From: Ekaterina Dimitrova
> Date: Monday, 30 May 2022 at 21:37
> T
be liberal with @SupressWarnings.
I’m not sure how we would transition, though, with so many existing warnings.
From: Ekaterina Dimitrova
Date: Monday, 30 May 2022 at 21:37
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
I also like it, thank you for
s? Everyone happy with the latest proposal?
>>
>>
>>
>> *From: *bened...@apache.org
>> *Date: *Sunday, 15 May 2022 at 15:08
>> *To: *dev@cassandra.apache.org
>> *Subject: *Re: Updating our Code Contribution/Style Guide
>>
>> I agree with this
ult.
>
>
>
> That said, as stated multiple times, the author and reviewer’s
> determinations are final. This document just sets up some basic
> parameters/expectations.
>
>
>
> *From: *Derek Chen-Becker
> *Date: *Saturday, 14 May 2022 at 20:56
> *To: *dev@cassandra.apache.o
Any more feedback around this? Everyone happy with the latest proposal?
From: bened...@apache.org
Date: Sunday, 15 May 2022 at 15:08
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
I agree with this sentiment, but I think it will require a bit of time to
ay, 14 May 2022 at 20:56
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
On Sat, May 14, 2022 at 11:00 AM Josh McKenzie
mailto:jmcken...@apache.org>> wrote:
Incidentally, I've found similar value in @ThreadSafe, const, readonly, etc -
communications of auth
o to
> avoid imbuing documents like this with too much power (and making them too
> contentious).
>
>
>
> I’ll see about tweaking it along with your other suggestions.
>
>
>
> *From: *Derek Chen-Becker
> *Date: *Saturday, 14 May 2022 at 20:45
> *To: *dev@cassandra.
:45
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
On Sat, May 14, 2022 at 8:24 AM bened...@apache.org<mailto:bened...@apache.org>
mailto:bened...@apache.org>> wrote:
> I'm in favor of codifying the usage of @NotNull and @Nullable styli
On Sat, May 14, 2022 at 11:00 AM Josh McKenzie wrote:
>
> Incidentally, I've found similar value in @ThreadSafe, const, readonly,
> etc - communications of author's intent; being able to signal to future
> maintainers helps them make modifications that are more consistent with and
> safer with re
On Sat, May 14, 2022 at 8:24 AM bened...@apache.org
wrote:
> > I'm in favor of codifying the usage of @NotNull and @Nullable
> stylistically. +1
>
>
>
> I’m in favour of the use of _*one*_ of @Nullable and @NotNull, preferably
> the former since we already use it and it’s more reasonable to have
> have a very obvious effect. I prefer to leave some decisions to the author,
> since we have expressed a strong preference here for the author to consider.
> But perhaps a blanket policy would do more good than harm. I could endorse
> it, and am relatively neutral.
>
>
o it!
Cheers,
Derek
From: "bened...@apache.org"
Reply-To: "dev@cassandra.apache.org"
Date: Friday, May 13, 2022 at 6:41 AM
To: "dev@cassandra.apache.org"
Subject: RE: [EXTERNAL]Updating our Code Contribution/Style Guide
CAUTION: This email originated from outside of th
idered, and I appreciate
> all of the work that went into it!
>
> Cheers,
>
> Derek
>
> *From: *"bened...@apache.org"
> *Reply-To: *"dev@cassandra.apache.org"
> *Date: *Friday, May 13, 2022 at 6:41 AM
> *To: *"dev@cassandra.apache.o
well written and carefully considered, and I appreciate all
of the work that went into it!
Cheers,
Derek
From: "bened...@apache.org"
Reply-To: "dev@cassandra.apache.org"
Date: Friday, May 13, 2022 at 6:41 AM
To: "dev@cassandra.apache.org"
Subject: RE: [EXTERNAL]Updat
the wiki.
From: bened...@apache.org
Date: Monday, 14 March 2022 at 09:41
To: dev@cassandra.apache.org
Subject: Updating our Code Contribution/Style Guide
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
> It looks like the doc already specified this behaviour for ternary
> operator line wrapping. For your proposal I’ve also added the following:
>
>
>
> It is usually preferable to carry the operator for multiline expressions,
> with the exception of some multiline string literals.
>
>
>
> Does that
should also be specifying spacing for loop
guards, conditions, casts, etc?
From: bened...@apache.org
Date: Sunday, 20 March 2022 at 21:37
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
> We are talking about one extra line, not a dozen or more.
I think you
at 20:56
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
> I support this too… leads to more noise in, and less readability of, the
> patch.
Readability of the patch is not harmed with modern tooling (with whitespace
being highlighted differently to
> I support this too… leads to more noise in, and less readability of, the
> patch.
>
>
>
> Readability of the patch is not harmed with modern tooling (with
> whitespace being highlighted differently to content changes).
>
>
>
> Legibility of the code (not patch) should always be preferred IMO. To
ject: Re: Updating our Code Contribution/Style Guide
On Tue, 15 Mar 2022 at 11:46, Ruslan Fomkin
mailto:ruslan.fom...@gmail.com>> wrote:
…
I support Jacek’s request to have each argument on a separate line when they
are many and need to be placed on multiple lines. For me it takes less ef
Regarding `instance()` method / `instance` field - to clarify my point - we
usually use that in many places. While it is quite easy to access by method
rather than by a field from the beginning, regardless if there is a need
for a mock immediately or not, it would be a much bigger change in terms o
On Tue, 15 Mar 2022 at 11:46, Ruslan Fomkin wrote:
> …
> I support Jacek’s request to have each argument on a separate line when
> they are many and need to be placed on multiple lines. For me it takes less
> effort to grasp arguments on separate lines than when several arguments are
> combined o
mports we probably want to mass correct them first. It’s not like other
> style requirements in that there should not be unintended consequences. A
> single (huge) commit to standardise the orders and introduce a build-time
> check would be fine IMO.
>
>
>
> I also don’t real
tions, 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 flex
> would be fine IMO.
>
>
>
> I also don’t really think it is that important.
>
>
>
> From: Jacek Lewandowski
> Date: Tuesday, 15 March 2022 at 05:18
> To: dev@cassandra.apache.org
> Subject: Re: Updating our Code Contribution/Style Guide
>
> I do think that
would
be fine IMO.
I also don’t really think it is that important.
From: Jacek Lewandowski
Date: Tuesday, 15 March 2022 at 05:18
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
I do think that we should at least enforce the import order. What is now is a
shi
> *Date: *Monday, 14 March 2022 at 23:44
> *To: *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 sty
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
> Date: Monday, 14 March 2022 at 23:44
> To: dev@cassandra.apache.org
> Subject: Re: Updating
rules are stated in a
flexible manner, so as to permit breaches where overall legibility and
aesthetics are improved.
From: Dinesh Joshi
Date: Monday, 14 March 2022 at 23:44
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
I am also in favor of updating the
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 co
s any necessary indentation (from the start of the
line, which is perfect for legibility). I am somewhat inlined to declare that
braces must be used if the lambda cannot fit on the declaring line.
From: Jacek Lewandowski
mailto:lewandowski.ja...@gmail.com>>
Date: Monday, 14 March 2022 at 14
e. I do not know why they are as they are.
>
>
>
> > - define continuation indent - currently it is 0 characters
>
>
>
> An opening brace introduces any necessary indentation (from the start of
> the line, which is perfect for legibility). I am somewhat inlined to
>
22 at 14:27
To: dev@cassandra.apache.org
Subject: Re: Updating our Code Contribution/Style Guide
Hi,
I was looking at the document and have some thoughts:
- Sometimes, although it would be just a single implementation, interface can
make sense for testing purposes - for mocking in particular
-
Hi,
I was looking at the document and have some thoughts:
- Sometimes, although it would be just a single implementation, interface
can make sense for testing purposes - for mocking in particular
- For exception handling, perhaps we should explicitly mention in the
guideline that we should alway
> we should add Python code style guides to it
>
Strongly agree. We're hurting ourselves by treating our python as a 2nd class
citizen.
> 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
> th
“discouraged”, but I am not aware of any context where it
is helpful today.
From: Marcus Eriksson
Date: Monday, 14 March 2022 at 12:00
To: 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
I agree on not using finals as suggested by Marcus, I have been using
them where I could, sometimes for the sake of having them final to be
consistent with other code but I gladly drop this habit. Too bad Java
doesnt have it like Scala where it is the matter of "var" vs "val".
On Mon, 14 Mar 2022
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 sho
ndra.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
Py
*Bowen Song
> *Date: *Monday, 14 March 2022 at 10:53
> *To: *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 to
?
From: Bowen Song
Date: Monday, 14 March 2022 at 10:53
To: 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 "fla
I think there's two separate issues, the style guide for Python code,
and fixing the existing code style. In my opinion, the style guide
should come first, and we can follow that to fix the existing code's style.
BTW, I can see the changes you made in CASSANDRA-17413 has already been
merged in
Hi Bowen,
we were working on that recently, like CASSANDRA-17413 + a lot of
improvements around Python stuff are coming. If you identify more
places for improvements we are definitely interested.
Regards
On Mon, 14 Mar 2022 at 11:53, Bowen Song wrote:
>
> I found there's no mentioning of Python
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
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 pa
48 matches
Mail list logo
