Can you please shed some light on what problem we'll solve by doing all this or what motivates us to go there?
To my mind, Solr is a burning platform, bordering on irrelevance because of years of neglect, and all these efforts just feel like arranging deck chairs on a sinking ship. Let's do it by all means if it solves anything, rather than doing this for the sake of doing something. On Thu, 2 Mar, 2023, 7:15 am David Smiley, <dsmi...@apache.org> wrote: > I wish to standardize our use of casing in names/symbols. And perhaps to > align with GJS more broadly. > > We use the google-java-format build plugin, which is obviously tightly > correlated with the Google Java Style. I think we/Solr jumped on board > with auto code formatting but didn't necessarily declare an intent to align > ourselves with GJS more broadly. I'd like us to do so now. I'm not > advocating for sweeping changes to follow from this, just an intent to > align future decisions. Maybe some previous things might get renamed as we > feel inclined. > > According to the Google Java Style[1], symbol names with acronyms should be > camel cased. Thus RebalanceLeadersAPI should be RebalanceLeadersApi, for > example. > > FWIW I've followed this approach for a long time and I find that it > produces more predictable results with fewer wonky scenarios. On the down > side, it's somewhat unsatisfying that acronyms aren't cased as would be > done in a natural (non-code) written form. But such forms have space as a > delimiter, unlike code. > > [1] https://google.github.io/styleguide/javaguide.html#s5-naming > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley >
