Hi Jon, thanks for the excellent questions, answers below
> Write Path - for recovery, how does a node safely recover the highest hybrid
> logical clock it has issued? Checking the last entry in the
> addressable log is insufficient unless we ensure every individual update is
> durable, rather t
If we extend automatic formatting beyond just braces, where does that end?
Are we going to place rules where static variables are? Static code blocks,
constructors, methods and private methods, setters, getters, toString,
equals ... Is the order of these things going to be directed as well?
Becaus
People who don’t take pride in the little things tend to have little pride in the big things. Pride is what produces better code that is more readable. I have experience with codebases where automatic formatters reign, and my experience is that it does not improve readability, it just encourages pe
I too had the same experience as Jon (not with Go but with a project that
had a pre-commit linter and another that did it in IntelliJ — much nicer
than the pre-commit formatter).
If we have a guide it should be as automatable as possible. I feel strongly
about that. From the responses I also think
Fwiw, I used to have the same opinion that I don't need or want an auto
formatter, than I tried Go where you don't have a choice. I realized how
pointless it was to do it manually. Every Go codebase looks the same, and
it's awesome.
I'd rather see C* be consistent with the majority of Java codeba
I’m amazed at the number of people who take no pride in their formatting decisions, and would abdicate responsibility to an automatic formatter.But, that’s fine and you should all feel welcome to do that. Just maybe don’t try to force it on those of us who do take pride in our formatting decisions?
And in an ideal world, we should never worry about the code style. Pointing
out code style issues in PRs is a waste of time for both contributors and
reviewers, imo.
On Fri, Jan 17, 2025 at 9:52 AM Cheng Wang wrote:
> Just share my personal experience as a new contributor to Cassandra.
> It's ab
Just share my personal experience as a new contributor to Cassandra.
It's about the new-line braces. My muscle memory is the same line braces,
so I need to set the Inteliij code style to have the Brace Placement option
to Next Line, and do a Reformat Code for the files I changed. Also, I need
to ch
As a personal feeling from reading the thread:
Am I right in thinking that we are forcing new contributors to read
long contribution guides (in addition to spending time writing them)
in favour of just pressing Option+Cmd+L (or other hotkeys in the IDE
they like) to format the code before committi
I had another read through for the CEP and had some follow up
questions/thoughts.
Write Path - for recovery, how does a node safely recover the highest
hybrid logical clock it has issued? Checking the last entry in the
addressable log is insufficient unless we ensure every individual update is
dur
If we can bake it into the two IDEA settings that control class and method opening brace placement, WFMOn Jan 17, 2025, at 8:28 AM, Štefan Miklošovič wrote:I am sorry if I read this incorrectly but the vibe I am getting is that we are going to rework that. On Fri, Jan 17, 2025 at 3:22 PM Štefan M
I am sorry if I read this incorrectly but the vibe I am getting is that we
are going to rework that.
On Fri, Jan 17, 2025 at 3:22 PM Štefan Miklošovič
wrote:
> Are really new-line braces so much pain? It is interesting to see this,
> really. What are the main problems with that? You can just fo
Are really new-line braces so much pain? It is interesting to see this,
really. What are the main problems with that? You can just format that by
shortcuts in IDEA and I suggested that we might explore how to make it the
part of generate-idea-files. What are we trying to solve by reformatting
2k+
As is tradition, this thread has split off into a few topics; fwiw I take this
as a very positive sign as it means we all care a lot about the project and
what we work on, and it's a sign we should maybe talk more frequently about
discrete topics instead of remembering adjacent topics when somet
> I’m not letting anyone near my carefully crafted code with an automated
> formatter.
Ha. Same.
Let’s not get carried away. The main problem here seems to be overzealous code
reviewers, and this can be solved with better reviewer onboarding / guide.
The minor formatting nits can and should be
I would support adopting a review guide based on this one.On 16 Jan 2025, at 15:36, Josh McKenzie wrote:Perhaps a “Review Guide” is what we need to make sure we keep review primarily focused on the core contribution, and to help avoid folk getting bogged down in style sniping.I recall reading thr
On Thu, 16 Jan 2025 at 22:06, Caleb Rackliffe
wrote:
> …
> There are forks out there, of course, and they would be affected, too.
>
This. Let's make sure to check thoroughly, this could really hurt people
(for what is a trivial annoyance).
Personally, braces on newlines doesn't bother me. I
I’m not letting anyone near my carefully crafted code with an automated formatter.On 17 Jan 2025, at 04:40, Abe Ratnofsky wrote:If breaking blame is a concern, we can address that with the ignore-revs-file flag in git and GitHub blame viewers: https://docs.github.com/en/repositories/working-with-
18 matches
Mail list logo
