BTW, I believe a rename of a file/class should *not* appear to git blame as happening on every line. Not something you said but maybe implied and not something I want to bring about with my proposal either.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Mar 8, 2023 at 1:16 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > 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 > > > > > > > > > >
