My biggest concern with widespread code changes, like the effort to format the entire codebase or to suppress warnings etc in the past, is that relevant history gets polluted. It isn't as easy to trace back changes to their issues by browsing code.
To me, reading code is easier if I can quickly follow links to jira/gh for lines I want to understand more about. Visual pleasantness is secondary when dealing with critical code, esp around SolrCloud. On Wed, 8 Mar, 2023, 10:11 pm Justin Sweeney, <justin.sweene...@gmail.com> wrote: > +1 If we do so, I'd suggest we also add that to the Contributing docs > somewhere so it is readily apparent for new contributors: > https://github.com/apache/solr/blob/main/CONTRIBUTING.md. > > On Wed, Mar 8, 2023 at 3:29 AM Bruno Roustant <bruno.roust...@gmail.com> > wrote: > > > +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 > > > > > >
