MOSA Tooling

Coordinator
Apr 14, 2009 at 8:39 AM
As some of you know I've setup a new CI server at work for the projects I'm involved with there. This has been a pretty nice experience using the following Tools:

- JetBrains TeamCity as a CI-Server
- Microsoft StyleCop
- Microsoft FxCop
- Microsoft Sandcastle for documentation
- Gallio/MbUnit for our tests

I've been always looking if we can reuse this for MOSA and think that we should in fact use these tools if we have the capability to do so. The Tools mentioned above are either free or we qualify to use them (TeamCity) as an open source project. I'm certain there's other tools we should use too. One of the things I've noticed is that using these Tools has greatly improved the quality of code I wrote and StyleCop has improved the readability of my code, even though it is picky.

Running StyleCop/FxCop on our current source code tree spits out way too many warnings/errors, but I had the same experience at work. Using a precommit SVN hook I enforced that only cleaned up code is committed and after approximately two months our entire codebase is clean of StyleCop violations and we don't have any FxCop errors or critical warnings anymore. There's a lot of value in using these tools. If we're working on a Server again, we should make sure that we can use these tools there. What do you think?
Developer
Apr 14, 2009 at 4:10 PM
I honestly had not heard of StyleCop - so I've taken a look. And just like FxCop, there are a few rules which rub me, personally, the wrong way. (I'm sure everyone has their varying opinions.) I think unilaterally requiring compliance with these as guidelines (though I know it isn't what you were suggesting) is a bit draconian, especially for such a small project (despite its momentus goals).

Oh, my favorite:
SA1027: Tabs are not allowed use spaces instead.
Like, WTF? It causes as many problems as it intends to solve... And some of my beefs are more opinion-oriented - we could obviously banter back and forth about them all day.

But from the way you guys have been talking, I definitely think TeamCity in general sounds cool. We know we use MbUnit now but we've talked about that changing. And Sandcastle makes me cringe but we'll need to tackle it sooner or later.

But I think FxCop and StyleCop will only create problems for us as an ultra-small project that is trying to grow. (As in, our standards need to be a bit softer for now.) And if we *do* want to run StyleCop and FxCop now, we should not make them pre-commit conditions as of yet. I don't want to chase away someone because they used an underscore prefix for a private field name in a class... I would probably be the type of person chased away, honestly.



On Tue, Apr 14, 2009 at 4:39 AM, __grover <notifications@codeplex.com> wrote:

From: __grover

As some of you know I've setup a new CI server at work for the projects I'm involved with there. This has been a pretty nice experience using the following Tools:

- JetBrains TeamCity as a CI-Server
- Microsoft StyleCop
- Microsoft FxCop
- Microsoft Sandcastle for documentation
- Gallio/MbUnit for our tests

I've been always looking if we can reuse this for MOSA and think that we should in fact use these tools if we have the capability to do so. The Tools mentioned above are either free or we qualify to use them (TeamCity) as an open source project. I'm certain there's other tools we should use too. One of the things I've noticed is that using these Tools has greatly improved the quality of code I wrote and StyleCop has improved the readability of my code, even though it is picky.

Running StyleCop/FxCop on our current source code tree spits out way too many warnings/errors, but I had the same experience at work. Using a precommit SVN hook I enforced that only cleaned up code is committed and after approximately two months our entire codebase is clean of StyleCop violations and we don't have any FxCop errors or critical warnings anymore. There's a lot of value in using these tools. If we're working on a Server again, we should make sure that we can use these tools there. What do you think?

Read the full discussion online.

To add a post to this discussion, reply to this email (mosa@discussions.codeplex.com)

To start a new discussion for this project, email mosa@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Apr 14, 2009 at 4:57 PM
StyleCop has the ability to turn off the warnings if necessary. So yes, we
would need to agree on the importance of individual rules. However StyleCop
checks for conformance to the Framework Design Guidelines, so I think we
should not turn off too many of them.

About your comment with the pre-commit hook: It only fires if *you* commit.
So if there's an underscore in there you were most likely the one that added
it. For preexisting code it isn't too hard to just refactor the name to
match the rules.

At work I'm using StyleCop with ReSharper and its StyleCop plugin, which
tells me all violations while I'm editing the source code. Additionally
StyleCop plugs into Visual Studio so you can run it from the context menu in
the current file or on an entire solution.

grover
Developer
Apr 14, 2009 at 6:28 PM
I guess I should have stated more clearly that StyleCop and FxCop warrant their own respective discussions and decisions.

I'm actually playing with the StyleCop plugin for Visual Studio already, and it is the most contrived of plugins in that all it offers is the ability to run the tool, and then display the output. Configuration options are not apparent from that end. I haven't combined it with ReSharper yet.

I understand the idea of a pre-commit hook firing when *I* commit, and that "problems" being there are *my* problems. I guess what I'm saying is that there are little nuances of detail on how multiple people code, and how different projects accept different standards, that make it rather dense to start enforcing on a codebase (and possible new contributors) that has a long way to grow before it will be publicly consumable.

It would be more effecient to refactor later, then to drag everyone down right now with strict standards. Frankly, the Warnings-As-Errors that you guys have set on all the project files is a P.I.T.A. enough as it is, but it at least keeps most of the API documented -- which is the only part of static style/usage analysis that, frankly, is immediately useful for us, IMHO.

And don't get me wrong, I would recommend we all use the tools locally. And even at least generate reports with CI. But I think we are a long way from prioritizing the requirement of them.

Also, NDepend is really nice. Though SharpOS never took advantage (out of forgetfulness) of the offer from Patrick Smacchia, I've been told that MOSA received the same offer and it is definitely something to ardently pursue. I've used the trial before on stuff for work, and it blew my mind. Good stuff, good stuff. (And we can shape guidelines around proposed acceptable metrics.)

On Tue, Apr 14, 2009 at 12:57 PM, __grover <notifications@codeplex.com> wrote:

From: __grover

StyleCop has the ability to turn off the warnings if necessary. So yes, we
would need to agree on the importance of individual rules. However StyleCop
checks for conformance to the Framework Design Guidelines, so I think we
should not turn off too many of them.

About your comment with the pre-commit hook: It only fires if *you* commit.
So if there's an underscore in there you were most likely the one that added
it. For preexisting code it isn't too hard to just refactor the name to
match the rules.

At work I'm using StyleCop with ReSharper and its StyleCop plugin, which
tells me all violations while I'm editing the source code. Additionally
StyleCop plugs into Visual Studio so you can run it from the context menu in
the current file or on an entire solution.

grover

Read the full discussion online.

To add a post to this discussion, reply to this email (mosa@discussions.codeplex.com)

To start a new discussion for this project, email mosa@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Apr 14, 2009 at 6:52 PM
Edited Apr 15, 2009 at 1:17 AM
I've taken a look at NDepend over the weekend and have used it on several
projects of mine. In theory its capabilities are mind-blowing, however I
found CQL to be sorely lacking. The standard queries are inadequate as they
made designer generated code (and other things, which aren't the fault of
the developer) the topmost hits - I've had to adjust almost every single one
of them to get reasonable results. There are also things I can imagine being
done with a join - something CQL unfortunately doesn't seem to support. And
finally I find the missing integration into Visual Studio or other IDEs to
be very uncomfortable - I hate to have to run an additional tool to
determine faults I'm making, which could've been easier to find if it were
integrated into VS and automatically ran after new (re-)builds.

Mike
Coordinator
Apr 14, 2009 at 8:44 PM
Edited Apr 15, 2009 at 1:16 AM
You can configure StyleCop settings in VS by right clicking any project in
solution explorer and selecting the "StyleCop Settings" menu item. I know
this is not obvious, but you can enable/disable every rule and perform
additional configuration there.
Developer
Apr 15, 2009 at 1:05 AM
Hehehe... I was getting ready to come to this thread to admit my oversight and I see you've left me with the same information I discovered.

It doesn't appear when you select the solution level, nor in the menu-bar system. But alas, 'tis there. I am now slightly more impressed with the Visual Studio integration. Though it pains me that ReSharper comes at such a high price.
Coordinator
Apr 15, 2009 at 4:44 AM

Mike (grover) - thanks for the input. I'm all for using those tools especially TeamCity, Gallio/MbUnit and Microsoft's StyleCop/FxCop.  I recently installed TeamCity - it looks promising - but got stuck since I installed it on Linux and we don't support the Linux environment yet.  I don't know much about the SandCastle yet. FxCop doesn't seem to work for me. StyleCop is awesome but the default ruleset is super picky. I'm still a newbie with that tool.

For those without ReSharper, I use the free version of "CodeRush Xpress for C# Developers" from: http://www.devexpress.com/Home/Announces/CodeRushXpress.xml.

As for StyleCop/FxCop: from a practical perspective and taking into consideration the current stage of development, I do not think we should enforce StyleCop/FxCop as part of the pre-commit process. I'd rather have the owner and "maintainers" go back in and fix styling issues once the code matures. Once we have a stable trunk, then I would recommend a stricter enforcement of our coding standards with those tools. But for now, as a way to encourage active and experimental development, I agree with Bruce (Illuminus) we should allow a relaxed coding style. Luckily, given the vast amount of development tools available and the existing team we will continue to have some order, structure and framework so it’s not likely to be the wild-wild west that we need to control.

So how about this, once the compiler mature and we get consensus, then we implement pre-commit with StyleCop/FxCop for that section of the trunk. And do the same later for the Kernel, Drive Drivers, etc. In the mean time, let's share and develop a customized StyleCop ruleset. Sound like a good plan?

Note: A long time ago, I added "CodeAnalysisDictionary.xml" for StyleCop.

Coordinator
Apr 15, 2009 at 9:10 AM
Hi everyone,

I contacted JetBrains yesterday about 10 free licenses of ReSharper for the active contributers to our group. Today I've received a reply from their Sales/Open Source responsible person: We can apply for a license key, which can be used by all contributors to our project. For free. However in order to qualify, we must:

- Have a public website (I assume CodePlex doesn't count from the terms I've read.)
- Have an active community, which IMO we are

I'll initiate the application process, once we fulfill the website requirement.

grover
Coordinator
Apr 15, 2009 at 3:07 PM
I wonder why CodePlex does not count. Anyway, I'll this is a motivator to get our own website and SVN back up. I'm traveling a bit this week but I'll work a bit harder to get it done next week.
 
Phil

Coordinator
Apr 15, 2009 at 6:45 PM
I did apply for the licenses using CodePlex, but there are several things on the application form, which make me unsure if we actually conform to the requirements. For example they're asking about a mailing list and a seperate forum. Another thing is they wanted our release page, which currently doesn't offer a release except for the release plan for 0.1 - We'll see if we get it or not, but I remain hopeful.

Mike
Developer
Apr 15, 2009 at 7:39 PM
As a temporary tooling solution for blog aggregation, I've thrown together a Yahoo Pipe, available via FeedBurner, of some "MOSA" bloggage.

Aggregated are posts from grover's blog, rootnode's blog, and my blog, of items marked in the "MOSA" category.

Yahoo Pipes are finnicky, so this is definitely only a temporary solution. If Phil or anyone else with repository access has a blog that I missed, which contains MOSA content, please send me a link.

Here is the unified feed:

http://feeds2.feedburner.com/MosaDevBlogs


Coordinator
Apr 15, 2009 at 8:18 PM
Cool stuff. Thanks!