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. On Mon, Jan 20, 2025, at 8:08 AM, Marcus Eriksson wrote: > 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): > > > https://issues.apache.org/jira/issues/?jql=labels%20%3D%20code-polishing > > > > > > On Sat, 18 Jan 2025 at 22:19, Dinesh Joshi <djo...@apache.org> wrote: > > > > > > > > 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 > > > > > > > > > > > > On Sat, Jan 18, 2025 at 1:07 PM Ekaterina Dimitrova > > > > <e.dimitr...@gmail.com> wrote: > > > >> > > > >> 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. > > > >> > > > >> On Sat, 18 Jan 2025 at 15:56, Blake Eggleston <beggles...@apple.com> > > > >> wrote: > > > >>> > > > >>> 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. > > > >>> > > > >>> > > > >>> On Jan 18, 2025, at 12:43 PM, Jon Haddad <j...@rustyrazorblade.com> > > > >>> wrote: > > > >>> > > > >>> + .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. > > > >>> > > > >>> https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> On Sat, Jan 18, 2025 at 12:32 PM Ekaterina Dimitrova > > > >>> <e.dimitr...@gmail.com> wrote: > > > >>>> > > > >>>> 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 <beggles...@apple.com> > > > >>>> wrote: > > > >>>>> > > > >>>>> 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. > > > >>>>> > > > >>>>> > > > >>>>> On Jan 18, 2025, at 9:40 AM, Štefan Miklošovič > > > >>>>> <smikloso...@apache.org> wrote: > > > >>>>> > > > >>>>> 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. > > > >>>>> > > > >>>>> On Sat, Jan 18, 2025 at 4:25 PM Benedict <bened...@apache.org> > > > >>>>> wrote: > > > >>>>>> > > > >>>>>> This is a mad idea that I can’t believe anyone is seriously > > > >>>>>> entertaining. -1. > > > >>>>>> > > > >>>>>> On 18 Jan 2025, at 13:17, Josh McKenzie <jmcken...@apache.org> > > > >>>>>> 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 > > > >>>>>> 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. > > > >>>>>> > > > >>>>> > > > >>> > > > >
