Thanks for moving this along! This is a good step in the right direction.
I hope that we get more source code validation at some point so that we don't need to constantly remind folks "We follow the Google Java Format" ;-). One thought…. If I set my IntelliJ to use the https://plugins.jetbrains.com/plugin/8527-google-java-format <https://plugins.jetbrains.com/plugin/8527-google-java-format> plugin, will it start changing the formats of my code and make diffs hard again? > On Mar 17, 2023, at 2:06 AM, David Smiley <dsmi...@apache.org> wrote: > > https://github.com/apache/solr/pull/1468 > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Wed, Mar 15, 2023 at 4:11 PM Justin Sweeney <justin.sweene...@gmail.com> > wrote: > >> +1 Could also be useful to link common IDE plugins in the dev docs to help: >> https://github.com/google/google-java-format#eclipse >> https://plugins.jetbrains.com/plugin/8527-google-java-format >> >> >> On Wed, Mar 15, 2023 at 3:55 PM Jan Høydahl <jan....@cominvent.com> wrote: >> >>> +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 >>> >>> >> _______________________ 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.
