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. > >>>>>> > >>>>> > >>> >
