+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 > >
