Home | About | Sematext search-lucene.com search-hadoop.com
 Search Lucene and all its subprojects:

Switch to Threaded View
Lucene.Net, mail # dev - Re: Outstanding issues for 3.0.3


Copy link to this message
-
Re: Outstanding issues for 3.0.3
Michael Herndon 2012-08-02, 16:39
if you do rename stuff other than poorly named signature parameters, its
helpful to document the java version's name and the reason for the rename.
Even for java, some of the internal naming makes the code that much harder
to understand and follow.

On Thu, Aug 2, 2012 at 12:33 PM, Prescott Nasser <[EMAIL PROTECTED]>wrote:

> Excellent Idea - I'll do that monday to give you guys the weekend to do
> any last minute code cleaning you want.
>
>
> ----------------------------------------
> > Date: Thu, 2 Aug 2012 19:30:02 +0300
> > Subject: Re: Outstanding issues for 3.0.3
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> >
> > Prescott - we could make an RC and push it to Nuget as a PreRelease, to
> get
> > real feedback.
> >
> > On Thu, Aug 2, 2012 at 7:13 PM, Prescott Nasser <[EMAIL PROTECTED]
> >wrote:
> >
> > > I don't think we ever fully adopted the style guidelines, probably not
> a
> > > terrible discussion to have. As for this release, I think that by lazy
> > > consensus we should branch the trunk at the end of this weekend (say
> > > monday), and begin the process of cutting a release. - my $.02 below
> > >
> > >
> > > > 1) Usage of "this" prefix when not required.
> > > >
> > > > this.blah = blah; <- required this.
> > > > this.aBlah = blah; <- optional this, which Re# doesn't like.
> > > >
> > > > I'm assuming consistency wins here, and 'this.' stays, but wanted to
> > > double check.
> > >
> > > I'd error with consistency
> > >
> > >
> > > >
> > > > 2) Using different conventions for fields and parameters\local vars.
> > > >
> > > > blah vs. _blah
> > > >
> > >
> > > > Combined with 1, Re# wants (and I'm personally accustomed to):
> > > >
> > > > _blah = blah;
> > > >
> > >
> > >
> > > For private variables _ is ok, for anything else, don't use _ as it's
> not
> > > CLR compliant
> > >
> > >
> > > > However, that seems to violate the adopted style.
> > > >
> > > > 3) Full qualification of type names.
> > > >
> > > > Re # wants to remove redundant namespace qualifiers. Leave them or
> > > remove them?
> > > >
> > >
> > > I try to remove them
> > >
> > > > 4) Removing unreferenced classes.
> > > >
> > > > Should I remove non-public unreferenced classes? The ones I've come
> > > across so far are private.
> > > >
> > >
> > > I'm not sure I understand - are you saying we have classes that are
> never
> > > used in random places? If so, I think before removing them we should
> have a
> > > conversation; what are they, why are they there, etc. - I'm hoping
> there
> > > aren't too many of these..
> > >
> > > > 5) var vs. explicit
> > > >
> > > > I know this has been brought up before, but not sure of the final
> > > disposition. FWIW, I prefer var.
> > > >
> > >
> > > I use var with it's plainly obvious the object var obj = new
> MyClass(). I
> > > usually use explicit when it's an object returned from some function
> that
> > > makes it unclear what the return value is:
> > >
> > >
> > > var items = search.GetResults();
> > >
> > > vs
> > >
> > > IList<SearchResult> items = search.GetResults(); //prefer
> > >
> > >
> > > >
> > > > There are some non-Re# issues I came across as well that look like
> > > artifacts of code generation:
> > > >
> > > > 6) Weird param names.
> > > >
> > > > Param1 vs. directory
> > > >
> > > > I assume it's okay to replace 'Param1' with something a descriptive
> name
> > > like 'directory'.
> > > >
> > >
> > > Weird - I think a rename is OK for this release (Since we're ticking
> up a
> > > full version number), but I believe changing param names can
> potentially
> > > break code. That said, I don't really think we need to change the
> names and
> > > push the 3.0.3 release out, and if it does in fact cause breaking
> changes,
> > > I'd be a little careful about how we do it going forward to 3.6.
> > >
> > > > 7) Field names that follow local variable naming conventions.
> > > >
> > > > Lots of issues related to private vars with names like i, j, k, etc.
> It
> >