+ .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 >>> <https://lists.apache.org/thread/8lzlc4x6g6yx766w738grxdcmqgwds7l>" >>> >>> 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: >>> >>> 1. 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) >>> 2. 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. >>> 3. 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. >>> 4. 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. >>> >>> >>
