I've put * my local git branch. On Fri, Aug 5, 2011 at 3:45 PM, Michael Herndon <mhern...@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 <lombardena...@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:mhern...@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 <thowar...@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 < >> geobmx...@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 >> > > >> >> >
