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