lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Herndon <mhern...@wickedsoftware.net>
Subject Re: [Lucene.Net] style cop, fx cop rules
Date Fri, 05 Aug 2011 19:45:08 GMT
Hey all,

I put an experimental branch up targeted towards lucene 4 called
Lucene.Net_4e  (e for experimental)

This was initially for me to provide an easier way to create the build
scripts and experiment with nuget, nunit, ncover, gallio, sandcastle, fxcop,
and the portable library project. I've my local git branch for that into the
project for the short term.

This should let everyone see how style cop wants you to code with the
default rules enabled.  You will need vs sp1 installed and PLP tools (
http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981/)
installed to open the project inside of visual studio.  To run the other
tools, look at the readme.txt.

I didn't want to further disrupt the v2.9.4g branch. When I'm done with the
build scripts I can backport those to trunk and v2.9.4g branch.

- Michael



On Mon, Aug 1, 2011 at 2:46 PM, Scott Lombard <lombardenator@gmail.com>wrote:

> The only problem with some modifying the code in this manor is it is going
> to make it difficult to manually port from Java.  Digy has talked about
> this
> in the past and can provide more detail.  The summary is that as the code
> and comments diverge from the Java code it gets harder port Java patches.
>  I
> am not sure where the balance is.
>
> Scott
>
> > -----Original Message-----
> > From: Michael Herndon [mailto:mherndon@wickedsoftware.net]
> > Sent: Monday, August 01, 2011 2:05 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: [Lucene.Net] style cop, fx cop rules
> >
> > StyleCop by default adheres strictly to ms coding guidelines and then
> > some.
> >  http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx (even
> though
> > a
> > deal of the internals of the framework breaks these rules).
> >
> > You can turns rules off but if you want rules that differ from the
> default
> > ones, rules would need to be created. Though a few of the rules do
> > look customizable.   I can install style cop into the project those into
> > the
> > project and turn off rules, anything further will be left up to
> > the community. Though I'd suggest turning rules down a notch for the
> > testing
> > projects.
> >
> > I can make scripts to run fxcop, but it will be left up to each
> individual
> > to install it. FxCop 10.0 only now comes with the win 7.1 sdk for .net 4
> > and
> > it does not seem to be redistributable.  And judging by the size of it
> > now.... Its probably best that isn't put into source anyways.
> >
> > On Mon, Aug 1, 2011 at 1:47 PM, Troy Howard <thoward37@gmail.com> wrote:
> >
> > > Agreed. StyleCop and FxCop are both quite handy and can only serve to
> > > benefit the project.
> > >
> > > -T
> > >
> > > On Mon, Aug 1, 2011 at 10:39 AM, Prescott Nasser <
> geobmx540@hotmail.com>
> > > wrote:
> > > >
> > > >
> > > >
> > > >>
> > > >> I don't think there's any harm in putting StyleCop in the project
at
> > > this
> > > >> stage, but of course, no harm not putting it in either. It would be
> > > handy
> > > >> for people who already have VS2008/2010, as we could keep Lucene
> with
> > > the
> > > >> same style format across the project as a whole.
> > > >>
> > > >
> > > >
> > > > We should move forward to enhance the project imo. Those who are
> still
> > > using 2005 can handle warnings if they pop up. It shoudln't be errors,
> > so
> > > nothing should be breaking
> > > >
> > > >
> > > >
> > > >> IMO, I think the Naming, Maintainability, and layour rules are the
> > most
> > > >> important. I use R#, so many of the default ones there are the ones
> > I'm
> > > >> partial to. For example, I like my private fields to start with
> > > >> underscores. I like my private properties, method names, public
> > fields
> > > to be
> > > >> in pascal case. I like local variables and method parameters to use
> > > camel
> > > >> case. I dislike hungarian notation. I like only one class per file,
> > and
> > > >> one namespace per file, those being in the maintainability rules.
> > > >>
> > > >
> > > >
> > > > +1, I'll also add I prefer one class per file as well, with some very
> > > rare exceptions (which for simplicity we could just say one class per
> > file)
> > > >
> > > >
> > > >
> > > >
> > > >> > It might be prudent to wait on putting style cop int the project,
> > it
> > > >> > currently doesn't have a command line client and if installed
it
> > would
> > > >> > generate warnings on each time someone builds on their local.
> > > >> >
> > > >> > - Michael.
> > > >> >
> > > >
> > > >
> > > >
> > > > If I recall correctly, we agreed to move forward with our support,
> > .Net 4
> > > (or at least 3.5) and VS2008/2010. Since Stylecop there isn't much
> > reason
> > > not to include it imo, if you're using 2005 still, then I think you
> > should
> > > accept that you'll get warnings
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ~Prescott
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message