Re: [DISCUSS] Bracing style on trunk

Hi, I do not care what bracing style we use. I do have a preferred one, but I don't care which one we use. I hate that we have check style, but not a gofmt equivalent. I would take any amount of churn pain to have a gofmt equivalent so I could stop thinking about style. I would not want the c

Re: [DISCUSS] Bracing style on trunk

I never should have mentioned this in the other thread in the first place. Just old/deep annoyance verbalized in an ultimately unhelpful way. It’s 15 years too late.On Jan 20, 2025, at 11:16 AM, Benedict wrote:These proposed refinements simply relax the wording of the style guide. That is, all cu

Re: [DISCUSS] Bracing style on trunk

These proposed refinements simply relax the wording of the style guide. That is, all current automated formatting would remain consistent with the style guide - though I would support also updating these, and wouldn’t mind helping to produce an update to our IntelliJ templateOn 20 Jan 2025, at 17:0

Re: [DISCUSS] Bracing style on trunk

While on the surface I would like to change the rules going forward, the special or hybrid rules sound like a nightmare for lingers. I’m -1 unless the change comes with functional changes to e.g. the idea files etc. if someone wants to take that on I’m all for modernizing the style guide. Jordan

Re: [DISCUSS] Bracing style on trunk

I think if we want to we can refine the rules a little while we’re all here discussing it anyway.We could for instance just stipulate the specific scenarios where it must happen, ie: multi-line if or loop blocks, and class or method declarations. This is the main actual historical style requirement

Re: [DISCUSS] Bracing style on trunk

On Mon, Jan 20, 2025 at 8:30 AM Josh McKenzie wrote: > So at least from my perspective w/the information I have, my opinion is we're > kind of stuck with what we have. I agree, -1 on changing this.. Kind Regards, Brandon

Re: [DISCUSS] Bracing style on trunk

There was 2 things from the initial thread that I conflated upon review. 1: Are we happy with our current bracing style formatting (general sentiment summates to "no"), and 2: were we to effect change, would doing it en masse be the way or gradually over time (far less sentiment expressed on thi

Re: [DISCUSS] Bracing style on trunk

Same, -1 On Mon, Jan 20, 2025 at 01:48:37PM GMT, Alex Petrov wrote: > I agree that switching bracing style is not something worth entertaining. -1 > from me, too. > > On Sun, Jan 19, 2025, at 1:34 AM, Maxim Muzafarov wrote: > > I'm leaning toward not changing the bracing style we already have >

Re: [DISCUSS] Bracing style on trunk

I agree that switching bracing style is not something worth entertaining. -1 from me, too. On Sun, Jan 19, 2025, at 1:34 AM, Maxim Muzafarov wrote: > I'm leaning toward not changing the bracing style we already have > unless there's a powerful reason (hard to imagine what it could be). > So curre

Re: [DISCUSS] Bracing style on trunk

I'm leaning toward not changing the bracing style we already have unless there's a powerful reason (hard to imagine what it could be). So currently -1. I would rather focus on enabling lints we all agree on, and/or the consensus is easy to achieve. There are many such lints, and much work to be don

Re: [DISCUSS] Bracing style on trunk

I honestly did not want to debate stylistic topics on a beautiful Saturday afternoon. As a project we have other, more pressing, topics to discuss. However, I just wanted to chime in and say that we have 3 options – 1. Continue placing the brace on a new line. 2. Move to accepting both new line br

Re: [DISCUSS] Bracing style on trunk

That is how I see it and how I personally understood you, Blake! Thanks! Also, Jon, appreciate your point of view too. I would support it for a new project though, Cassandra codebase is too big, too old, and too active IMHO for such a lift. Also, from my experience being around for about 5 years a

Re: [DISCUSS] Bracing style on trunk

Just to be clear, I do think it would be good for the project to conform to a more standard java style. I just think that the contributor friction from this issue is pretty small, and the impact to work in progress would be pretty severe. If the goal is to reduce contributor friction, there's pr

Re: [DISCUSS] Bracing style on trunk

+ .9 for me. I think it would be a good thing for the project in the long run to conform to a more standard Java style, but I'm unable to provide any time to make it happen. I don't think it's reasonable to impose this burden on anyone if I'm not willing to take it on myself, so this is why I'm n

Re: [DISCUSS] Bracing style on trunk

I also do not see huge benefit in switching the style, honestly. And I see risks more than benefits. I also share Blake’s opinion that this would be more suitable for a new project. On Sat, 18 Jan 2025 at 15:27, Blake Eggleston wrote: > I lean pretty strongly towards -1 on this. If we were star

Re: [DISCUSS] Bracing style on trunk

I lean pretty strongly towards -1 on this. If we were starting a new project, then yeah it would make sense. As an older project though, I don’t see any clear benefits for switching the style at this point, and can foresee it causing a lot of pain. Even if we were to wait for accord before going

Re: [DISCUSS] Bracing style on trunk

I agree with Benedict wholeheartedly. Yes, I am happy where the braces currently are and I don't understand that placing braces and the whole "problematic" is such a big topic for other people. 99% of problems with braces are caused by people not having their formatter in IDEA (or any IDE of thei

Re: [DISCUSS] Bracing style on trunk

This is a mad idea that I can’t believe anyone is seriously entertaining. -1.On 18 Jan 2025, at 13:17, Josh McKenzie wrote:Trying to break out discussions here to keep things moving - see thread "Checkstyle as style contract for Cassandra"One topic that came up on the thread was whether we were c

[DISCUSS] Bracing style on trunk

Trying to break out discussions here to keep things moving - see thread "Checkstyle as style contract for Cassandra " One topic that came up on the thread was whether we were collectively happy with our current newline bracing st