Let's record this somewhere then. I took a look in dev-docs/ and found the FAQ with an entry "How do we ensure coding standards and quality?" This seems like a natural place to put this. WDYT?
For the wording text, I want to keep it simple. Like the following: > Please follow the Google Java Style Guide[1]. We don't follow all aspects strictly; much code was written before this style guide was selected. Some aspects of this guide are automatically enforced by the build. I can raise a PR where the specifics can be further debated. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Mar 15, 2023 at 9:32 AM Eric Pugh <ep...@opensourceconnections.com> wrote: > 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. > >
