Why do you think the IntelliJ "Google Java Format" plugin will start changing formats beyond what Spotless is doing? Spotless uses GJF :-). Okay there's more to it than that... I recall the IntelliJ plugin variant also honors some Java import statement order stuff but the Spotless plugin doesn't. It's fine. If you see lots of changes then tag me; I'd be curious to see.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Mar 20, 2023 at 2:05 PM Eric Pugh <ep...@opensourceconnections.com> wrote: > 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. > >
