You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Michael Herndon <mh...@wickedsoftware.net> on 2011/07/28 04:11:51 UTC
[Lucene.Net] style cop, fx cop rules
Does anyone have any preferred rules that they want ignored or want required
for the project for either Fx Cop or Style Cop?
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.
Re: [Lucene.Net] style cop, fx cop rules
Posted by Michael Herndon <mh...@wickedsoftware.net>.
I've put * my local git branch.
On Fri, Aug 5, 2011 at 3:45 PM, Michael Herndon <mherndon@wickedsoftware.net
> wrote:
> 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 <lo...@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 <th...@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
>> > >
>>
>>
>
Re: [Lucene.Net] style cop, fx cop rules
Posted by Michael Herndon <mh...@wickedsoftware.net>.
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 <lo...@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 <th...@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
> > >
>
>
RE: [Lucene.Net] style cop, fx cop rules
Posted by Scott Lombard <lo...@gmail.com>.
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 <th...@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 <ge...@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
> >
Re: [Lucene.Net] style cop, fx cop rules
Posted by Michael Herndon <mh...@wickedsoftware.net>.
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 <th...@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 <ge...@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
>
Re: [Lucene.Net] style cop, fx cop rules
Posted by Troy Howard <th...@gmail.com>.
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 <ge...@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
RE: [Lucene.Net] style cop, fx cop rules
Posted by Prescott Nasser <ge...@hotmail.com>.
>
> 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
Re: [Lucene.Net] style cop, fx cop rules
Posted by Christopher Currens <cu...@gmail.com>.
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.
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.
I would like to hear other people's opinions on this, or maybe one of us
should just make a rule set and have everyone else look over it.
Thanks,
Christopher
On Wed, Jul 27, 2011 at 7:11 PM, Michael Herndon <
mherndon@wickedsoftware.net> wrote:
> Does anyone have any preferred rules that they want ignored or want
> required
> for the project for either Fx Cop or Style Cop?
>
> 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.
>