So what happens next? I’d love to see some of these topics get to decided ;-)
> On Mar 8, 2023, at 3:22 PM, David Smiley <dsmi...@apache.org> wrote: > > 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 >>>>> >>>> >>> >> _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
