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