You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by David Smiley <ds...@apache.org> on 2023/03/02 01:45:17 UTC
Google Java Style: shall we declare intent to follow?
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
Re: Google Java Style: shall we declare intent to follow?
Posted by Jan Høydahl <ja...@cominvent.com>.
+1, good idea.
Jan
> 2. mar. 2023 kl. 02:45 skrev David Smiley <ds...@apache.org>:
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Google Java Style: shall we declare intent to follow?
Posted by David Smiley <ds...@apache.org>.
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 <ds...@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.sweeney77@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 <ja...@cominvent.com>
> wrote:
> >>
> >>> +1 to David's proposal.
> >>>
> >>>
> >>>> 15. mar. 2023 kl. 19:07 skrev David Smiley <ds...@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 <
> >>> epugh@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 <ds...@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 <
> >>>>>> ichattopadhyaya@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.sweeney77@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.roustant@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 <
> anshum@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 <dsmiley@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-unsubscribe@solr.apache.org
> >>> For additional commands, e-mail: dev-help@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.
>
>
Re: Google Java Style: shall we declare intent to follow?
Posted by Eric Pugh <ep...@opensourceconnections.com>.
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 <ds...@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 <ju...@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 <ja...@cominvent.com> wrote:
>>
>>> +1 to David's proposal.
>>>
>>>
>>>> 15. mar. 2023 kl. 19:07 skrev David Smiley <ds...@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 <
>>> epugh@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 <ds...@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 <
>>>>>> ichattopadhyaya@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.sweeney77@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.roustant@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 <anshum@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 <ds...@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-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@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.
Re: Google Java Style: shall we declare intent to follow?
Posted by David Smiley <ds...@apache.org>.
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 <ju...@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 <ja...@cominvent.com> wrote:
>
> > +1 to David's proposal.
> >
> >
> > > 15. mar. 2023 kl. 19:07 skrev David Smiley <ds...@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 <
> > epugh@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 <ds...@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 <
> > >>> ichattopadhyaya@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.sweeney77@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.roustant@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 <anshum@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 <ds...@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-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>
Re: Google Java Style: shall we declare intent to follow?
Posted by Justin Sweeney <ju...@gmail.com>.
+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 <ja...@cominvent.com> wrote:
> +1 to David's proposal.
>
>
> > 15. mar. 2023 kl. 19:07 skrev David Smiley <ds...@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 <
> epugh@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 <ds...@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 <
> >>> ichattopadhyaya@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.sweeney77@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.roustant@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 <an...@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 <ds...@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-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Google Java Style: shall we declare intent to follow?
Posted by Jan Høydahl <ja...@cominvent.com>.
+1 to David's proposal.
> 15. mar. 2023 kl. 19:07 skrev David Smiley <ds...@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 <ds...@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 <
>>> ichattopadhyaya@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.sweeney77@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.roustant@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 <an...@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 <ds...@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-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Google Java Style: shall we declare intent to follow?
Posted by David Smiley <ds...@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 <ds...@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 <
> > ichattopadhyaya@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.sweeney77@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.roustant@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 <an...@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 <ds...@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.
>
>
Re: Google Java Style: shall we declare intent to follow?
Posted by Eric Pugh <ep...@opensourceconnections.com>.
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 <ds...@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 <
> ichattopadhyaya@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, <ju...@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 <br...@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 <an...@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 <ds...@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.
Re: Google Java Style: shall we declare intent to follow?
Posted by David Smiley <ds...@apache.org>.
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 <
ichattopadhyaya@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, <ju...@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 <br...@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 <an...@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 <ds...@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
> > > >
> > >
> >
>
Re: Google Java Style: shall we declare intent to follow?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
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, <ju...@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 <br...@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 <an...@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 <ds...@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
> > >
> >
>
Re: Google Java Style: shall we declare intent to follow?
Posted by Justin Sweeney <ju...@gmail.com>.
+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 <br...@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 <an...@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 <ds...@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
> >
>
Re: Google Java Style: shall we declare intent to follow?
Posted by Bruno Roustant <br...@gmail.com>.
+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 <an...@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 <ds...@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
>
Re: Google Java Style: shall we declare intent to follow?
Posted by Anshum Gupta <an...@anshumgupta.net>.
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 <ds...@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
Re: Google Java Style: shall we declare intent to follow?
Posted by Houston Putman <ho...@apache.org>.
I am always +1 for standardization, especially across a project as big as
this.
On Thu, Mar 2, 2023 at 9:09 AM Eric Pugh <ep...@opensourceconnections.com>
wrote:
> I often find myself bike shedding names of classes and variables….
>
> I also see contributions from folks who haven’t been in the Solr codebase
> for a long period of time introducing new patterns, so you end up reviewing
> code style more then code quality/intent.
>
> I’m a very much +1 for this.
>
>
> > On Mar 2, 2023, at 8:49 AM, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >
> > Cool, thanks for the additional context. +1 to this effort.
> >
> > On Thu, Mar 2, 2023 at 7:18 PM David Smiley <ds...@apache.org> wrote:
> >
> >> On Thu, Mar 2, 2023 at 6:23 AM Ishan Chattopadhyaya <
> >> ichattopadhyaya@gmail.com> wrote:
> >>
> >>> Can you please shed some light on what problem we'll solve by doing all
> >>> this or what motivates us to go there?
> >>>
> >>
> >> I suppose any of us could google such a generic question and find a
> bunch
> >> of reasonable answers. Pick any that you like; whatever. I find
> >> inconsistencies to read as sloppy and without attention to care. That
> is
> >> somewhat related to your second point; sloppiness is a sign of neglect.
> >> Anyway, I'm not advocating any additional work, just intentionality in
> >> choosing how code is styled instead of haphazardly. My intention is
> not to
> >> create extra work whose energies could be spent elsewhere more
> fruitfully.
> >>
>
> _______________________
> 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.
>
>
Re: Google Java Style: shall we declare intent to follow?
Posted by Eric Pugh <ep...@opensourceconnections.com>.
I often find myself bike shedding names of classes and variables….
I also see contributions from folks who haven’t been in the Solr codebase for a long period of time introducing new patterns, so you end up reviewing code style more then code quality/intent.
I’m a very much +1 for this.
> On Mar 2, 2023, at 8:49 AM, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>
> Cool, thanks for the additional context. +1 to this effort.
>
> On Thu, Mar 2, 2023 at 7:18 PM David Smiley <ds...@apache.org> wrote:
>
>> On Thu, Mar 2, 2023 at 6:23 AM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>>
>>> Can you please shed some light on what problem we'll solve by doing all
>>> this or what motivates us to go there?
>>>
>>
>> I suppose any of us could google such a generic question and find a bunch
>> of reasonable answers. Pick any that you like; whatever. I find
>> inconsistencies to read as sloppy and without attention to care. That is
>> somewhat related to your second point; sloppiness is a sign of neglect.
>> Anyway, I'm not advocating any additional work, just intentionality in
>> choosing how code is styled instead of haphazardly. My intention is not to
>> create extra work whose energies could be spent elsewhere more fruitfully.
>>
_______________________
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.
Re: Google Java Style: shall we declare intent to follow?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Cool, thanks for the additional context. +1 to this effort.
On Thu, Mar 2, 2023 at 7:18 PM David Smiley <ds...@apache.org> wrote:
> On Thu, Mar 2, 2023 at 6:23 AM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
> > Can you please shed some light on what problem we'll solve by doing all
> > this or what motivates us to go there?
> >
>
> I suppose any of us could google such a generic question and find a bunch
> of reasonable answers. Pick any that you like; whatever. I find
> inconsistencies to read as sloppy and without attention to care. That is
> somewhat related to your second point; sloppiness is a sign of neglect.
> Anyway, I'm not advocating any additional work, just intentionality in
> choosing how code is styled instead of haphazardly. My intention is not to
> create extra work whose energies could be spent elsewhere more fruitfully.
>
Re: Google Java Style: shall we declare intent to follow?
Posted by David Smiley <ds...@apache.org>.
On Thu, Mar 2, 2023 at 6:23 AM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:
> Can you please shed some light on what problem we'll solve by doing all
> this or what motivates us to go there?
>
I suppose any of us could google such a generic question and find a bunch
of reasonable answers. Pick any that you like; whatever. I find
inconsistencies to read as sloppy and without attention to care. That is
somewhat related to your second point; sloppiness is a sign of neglect.
Anyway, I'm not advocating any additional work, just intentionality in
choosing how code is styled instead of haphazardly. My intention is not to
create extra work whose energies could be spent elsewhere more fruitfully.
Re: Google Java Style: shall we declare intent to follow?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Can you please shed some light on what problem we'll solve by doing all
this or what motivates us to go there?
To my mind, Solr is a burning platform, bordering on irrelevance because of
years of neglect, and all these efforts just feel like arranging deck
chairs on a sinking ship. Let's do it by all means if it solves anything,
rather than doing this for the sake of doing something.
On Thu, 2 Mar, 2023, 7:15 am David Smiley, <ds...@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
>