+1 I find that a standard is more productive because I wouldn't have to question anymore about what is the consistent naming/pattern to use.
Le mar. 7 mars 2023 à 19:05, Anshum Gupta <ans...@anshumgupta.net> a écrit : > I like the idea, David. Overall it makes for code that is easier to read > and understand, specially for new contributors. > > > On Wed, Mar 1, 2023 at 5:46 PM 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 > > > > > -- > Anshum Gupta >
