+1 to David's proposal.
> 15. mar. 2023 kl. 19:07 skrev David Smiley <dsmi...@apache.org>: > > 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. >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
