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 this topic; what was expressed was receptive but very small minority).
- For newline vs. same line, I'm -0 on the status quo. I find it slightly silly and inefficient but am used to it.
- For "big bang vs. gradually over time", I'm actually -1 on both. Big Bang would be a very painful thing to coordinate and have a long tail, and gradual would leave us with a codebase with inconsistent formatting between files (and invariably within files) and be its own special hell.
So at least from my perspective w/the information I have, my opinion is we're kind of stuck with what we have.
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
> > 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 done.
> >
> >
> > What I don't agree with is that "post-accord" merging things. If that
> > is an exception, it's not a problem, I believe in flexibility. If this
> > is a rule of thumb, then we will never progress in an active community
> > with such lints and code cleanup because the development of important
> > features will always be running.
> >
> > The patches (the import order and the javadocs) have been waiting for
> > an important merge to happen for YEARS (no progress since then):
> >
> > >
> > > 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 braces and braces on the same line.
> > > 3. Adopt braces on the same line and not reformat the whole codebase.
> > >
> > > Irrespective of the choice of option, reformatting our codebase is a non-starter as it will kill productivity.
> > >
> > > If there are exceptions to a formatting rule we should try and enumerate a couple examples for clarity.
> > >
> > > thanks,
> > >
> > > Dinesh
> > >
> > >
> > >>
> > >> 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 already - easy wide-spread changes normally bring the most friction. I burnt myself with that in the past. Thus my position, being extra cautious.
> > >>
> > >> Though if the majority of the people see it in a different way - I am open to change position following the right arguments and I am not going to stay on the way. Thank you all. Curious to hear more points of view.
> > >>
> > >>>
> > >>> 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 probably lower hanging fruit that's less disruptive.
> > >>>
> > >>>
> > >>>
> > >>> + .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 not a +1.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>
> > >>>> 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.
> > >>>>
> > >>>>>
> > >>>>> 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 forward, and address any issues with git blame, there are a lot of other in-flight projects that would have to deal with this, there are a lot of tickets waiting for review that would be affected.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 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 their choosing) set up correctly. Setting up a formatter in your IDE is a perfectly normal thing to do.
> > >>>>>
> > >>>>> I am trying to figure out how to set this up automatically so when people hit formatting shortcuts, the braces would be put where they should be.
> > >>>>>
> > >>>>> I do not think that "well but I need to think about formatting and hitting that shortcut!" is a valid point. Come on folks ... one shortcut away and your code is formatted as it should be.
> > >>>>>
> > >>>>> If somebody has very special requirements for placing braces for very specific scenarios for better readability (one-liners, lambdas ...) we should enable them to do so.
> > >>>>>
> > >>>>>>
> > >>>>>> This is a mad idea that I can’t believe anyone is seriously entertaining. -1.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> 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 style and, if not, what we might do about it. The following points came up:
> > >>>>>>
> > >>>>>> We would do this post-accord merging so as not to cause significant rebase pains for the branch (unless active accord devs advocate for otherwise)
> > >>>>>> re: git history pollution, Abe pointed out that we can use a --ignore-revs-file option in git to switch bracing style in one go and keep our history.
> > >>>>>> Caleb advocated for limiting ourselves to trunk only. Given only bugfixes go to older branches this would limit our surface area of change quite a bit.
> > >>>>>> Mick seconded raised concerns about forks absorbing pain. We have multiple fork owners on the thread in favor of making the change, but it's worth keeping in mind.
> > >>>>>>
> > >>>>>> In general, sentiment was clearly skewed towards changing our bracing style on trunk to have braces on the same line as preceding control flow statement, closing braces on newline.
> > >>>>>>
> > >>>>>
> > >>>
> >
