From Microsoft….
Source Analysis is similar in many ways to Microsoft Code Analysis (specifically
FxCop), but there are some important distinctions. FxCop performs its analysis
on compiled binaries, while Source Analysis analyzes the source code directly.
For this reason, Code Analysis focuses more on the design of the code, while
Source Analysis focuses on layout, readability and documentation. Most of that
information is stripped away during the compilation process, and thus cannot be
analyzed by FxCop.
The ultimate goal of Source Analysis is to allow you to produce elegant,
consistent code that your team members and others who view your code will find
highly readable.
In order to accomplish this, Source Analysis does not allow its rules to
be very configurable. Source Analysis takes a one-size-fits-all approach
to code style, layout, and readability rules.
It is highly likely that you will not agree with all of the rules and may even
find some of the rules annoying at first! However, the majority of teams using
this tool within Microsoft have found that after a short adjustment period, they
came to appreciate the rules enforced by Source Analysis, and even began to find
it difficult to read code not written in this style.
Source Analysis comes with a set of default rules analyzers covering
approximately 200 best practice rules. These rules are full compatible with the
default layout settings in Visual Studio 2005 and Visual Studio 2008.
I’ve downloaded it and tried it on a project I was working on for home.
In a 428 line CS file, I had only 148 violations. :)
A few of them I’m a bit surprised by I suppose, like the requirement that
function calls must be prefixed with this.
“A comment may not be placed within the bracketed statement” and
“A line may only contain a single statement”:
} // catch
catch { }
} // attachment loop
OK, I’ll give them the catch is a bit odd (my code just gobbles any
exceptions), but I don’t know that I understand why I can’t put a
comment after a bracket (it’s just marking the end of a block).
“All using directives must be placed inside of the namespace.”
Eh? Why?
“Variable names must not start with m_”
Got that one wrong, I occasionally use s_ to indicate static instance fields.
It’s misfiring on that one.
“Field names must not start with an underscore.”
Yeah, OK. No thanks. I like doing that and I’m not about to switch to
prefixing everything with “this.” instead of an underscore. Bzzzt.
“An opening curly bracket must not be followed by a blank line.”
Oh my heavens! A blank line after a curly bracket?
Seriously though — if you’re wanting a rigorous source code formatting
analysis tool, check
this
out. If you buy into all of their rules — it’s all good. If you
don’t follow all of Microsoft’s C# conventions (some which I
wasn’t aware of), then you may be in for a rude awakening.
Unfortunately, the thing that I’d like to have as a feature would be for it to
optionally FIX the code to match the rules. Especially the easy stuff like blank
lines and curly braces. I wouldn’t want it to touch variable names, etc. But
the simple stuff … (oooh, and if it could rearrange the methods to be in the
suggested order, like statics first, etc…..!!).
