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 < > ichattopadhy...@gmail.com> wrote: > > > > Cool, thanks for the additional context. +1 to this effort. > > > > On Thu, Mar 2, 2023 at 7:18 PM David Smiley <dsmi...@apache.org> wrote: > > > >> On Thu, Mar 2, 2023 at 6:23 AM Ishan Chattopadhyaya < > >> ichattopadhy...@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. > >
