First question: do you use FxCop? Do I…not really. But I try not to tell too many people that either.
So there is a new tool out there for all of you who need help keeping your source code up to snuff, similar to what FxCop does for your API…just at the source code level. It is called the Microsoft Source Analysis for C# (sorry VB). BTW, there is also a blog.
I happen to have a project that I am in the midst of doing some spring cleaning anyway, so I decided to try it out. You right click on the project or class you want to check, and select “Run Source Analysis”. Then in a tool window you will see a list of your failings as a developer.
Right off the bad I had a few issues with the list of failures. Every code file has to have a header.
Here is my “new” standard header to make it happy:
1: // <copyright file="Axis.cs" company="DiamondB Software">
2: // Copyright 2008, DiamondB Software. All rights reserved.
3: // </copyright>
Lucky for me ReSharper can make that easy to add, but the ReSharper standard “File Header Text” in the ReSharper options does not allow you to have macros, or that would have been a lot easier.
Also, the Source Analysis does not like underscores on field names. So this will get a red ‘x’
private string _name;
and that is just not right. In fact, I want just the opposite. (Note: although, this will make one cranky old dutchman that I know very happy — he doesn’t like underscores).
But lucky for me, it is easy to turn things off, which I do. Right-click on your project file and select “Source Analysis Settings” and you can change anything you want. The bad news, it is on a project by project basis. The good news is that the files are merge-able. This also means there is a new file that gets added to your project, mine is: Settings.SourceAnalysis. Be sure to add that to your source control. 🙂
The other thing I like about it: it detects Hungarian notation (a prior sin that I am currently making penance for). “SA1305: The variable name ‘oElement’ begins with a prefix that looks like Hungarian notation.” But, if you like that sort of thing, back in the options is a way to tell the tools which Hungarian prefixes are acceptable.
But this could get ugly
OK, there are a few other concerns looming here. I’m calling it Dueling Source Officers. One tool will say two spaces between methods, the next will say one space. One tool like spaces, the other likes tabs. (for the record, Source Analysis HATES tabs, and thinks multiple lines between methods is plane evil). The other officer: ReSharper Code Analysis and ReSharper Code Reformat. Lucky for us ReSharper’s tools are very configurable…but it could take a while to get the two in sync.
Not throw in FxCop (now integrated into the Team Systems version of Visual Studio) and it can get very interesting.
Next steps
The next steps are simple:
1. Learn how to write your own rules (I want my underscores)
2. Figure out how to integrate into Team City and Cruise Control (Code Analysis ships with an MSBuild task), and get something meaning full out of it.
If you want a first hint at how to write your own rules – I was curious as well about that and put together a small post:
http://saftsack.fs.uni-bayreuth.de/~dun3/archives/writing-your-own-rules-for-microsoft-source-analysis-for-c/153.html
I know it is not much – but it might get you started in the right direction.
On regards to Source Analysis: I found it quite funny that the default Console Application shipping with VS would not even pass the tests. 😉
Cheers,
Tobi
@Tobias: OK, here is what I have found so far on writing add-ins.
First: there are three important files:
Microsoft.SourceAnalysis.dll
Microsoft.SourceAnalysis.CSharp.dll <- parses C# document Microsoft.SourceAnalysis.CSharp.Rules.dll If you look at SpacingRules, here is your inheritance tree: SpacingRules, Microsoft.SourceAnalysis.CSharp.Rules SourceAnalyzer, Microsoft.SourceAnalysis SourceAnalysisAddIn, Microsoft.SourceAnalysis SourceAnalyzer has several virtual functions that you will have to implement: AnalyzeDocument and DelayAnalysis. Via both of them you get a CodeDocument object. CodeDocument is actually another abstract class, the real class is CsDocument. Interesting, it looks like everything is implemented in such a way that adding VB support is actually possible (just not currently done).
I had the same issue with underscores in field names. Though I’m in the opposite camp, personally, I can’t convince co-workers to get rid of them … can I trade a few of mine for your cranky, old Dutchman?
The first thing I did was investigate writing a custom rule to do this: http://lovethedot.blogspot.com/2008/05/creating-custom-rules-for-microsoft_6976.html
I’ll probably find some “gotchas” as time goes on, but for now it’s working well on our code.
Boo, underscores! They are the last remnant of the discredited Hungarian notation.
Now, lets argue about where to put the curly braces! 🙂
@trasa, I like knowing where my variables are declared, plus it keeps me from having to worry about variable scoping. Otherwise I’d end up declaring my local variables like this: string localName;
Sorry, I had a prior horror of working on a delphi project with a slightly incompetent developer. Delphi allowed global values. So in his globals section he declared:
CHB: char;
Then in his procedures, he declared:
CHB: int;
All over the blasted place. The global version of CHB was a ‘C’, ‘H’, or a ‘B’, the local version was a 1,2, or 3. I could have killed him (if he didn’t live in another state). Sorry, after dealing with that, I will scope my variables.
As for curly braces, I’m having that discussion every hour right now with a guy I’m working with.
@chris, I just use R# to identify that sort of scoping issue for me 🙂
why stop at _? m_module_level_variable_type_string_firstName (i’m kidding..)
I suppose with autogenerated properties, 90% of your _variables go away now anyhow.
@trasa:
I agree with you about the ‘m’, I got rid of those a while back as well (at the request of my manager…who shall not be named…and who also blogs on elegant code.
The problem with your variable name is that it breaks another rule, you can’t have underscores INSIDE variable names.
And auto properties help…as long as your properties don’t need to do anything interesting (default values, raise event when changed, etc).
@chris: I’m mostly trolling at this point, name your private fields whatever you want 😉
[troll]with R# it’s also trivial to rename ’em later muhuhahaha[/troll]
OK i’ll stop now promise 🙂