Product Review: FMS Total
.NET Analyzer
VS.NET, Danny J. Lesandrini
12/2003 Looking for a tool that will not only make your code
better but will also, at the same time, make you a
better coder? If so, you might want to give FMS
Total .NET Analyzer a look. Danny Lesandrini
provides a great introduction to what this tool does
and what it can do for you.
I've been putting off this product review because I'm not an
expert in .NET and I don't want to pass myself off as one. Oddly
enough, my inexperience with VB.NET is exactly what made it
possible for me to appreciate this product, Total .NET Analyzer
by FMS Inc. So, whether you're a .NET expert or a novice, you
may benefit from this helpful tool.
FMS is the leading developer of tools for Microsoft
application developers. Their award-winning utilities for
Microsoft Access are a must for any serious Access programmer.
In 1998 they broke into the Visual Basic market, and in 2001
they introduced a line of SQL Server analysis utilities. When
Visual Studio .NET was released, FMS was ready with several
products, including a cross-reference utility, a code library,
and a code analysis tool. This review focuses on the latter, FMS
Total .NET Analyzer, but you can read about their entire line at
http://www.fmsinc.com.
Let me begin by telling you up front what it's going to cost
and what you'll get for those precious IT budget dollars. The
price for a single user license is $499, which makes this
product among the most expensive of third-party tools I've
reviewed. There are quantity breaks when purchasing multiple
licenses and when buying it as part of the Total NET Development
Suite, bundled with the other .NET tools mentioned earlier.
According to the FMS Web site, Total .NET Analyzer increases
the quality and performance of your Microsoft Visual Studio .NET
applications. With lightning-quick speed, Total .NET Analyzer
detects more than 150 potential issues in your C# and Visual
Basic .NET project source code. A punch list of what you can
expect includes the following:
? Quickly get up to speed in .NET
? Improve performance
? Avoid .NET traps and hidden bugs
? Learn .NET best practices
? Simplify code management
Does Total .NET Analyzer live up to the hype?
Many VB developers are easing their way into .NET projects with
nothing more than years of classic VB experience and a couple of good
.NET instruction books. If that's the situation you're in, then yes, FMS
Total .NET Analyzer will live up to the hype and deliver. It will help
you get up to speed, improve performance, remove hidden bugs, and teach
you .NET best practices.
About a year ago, I started my first commercial .NET project:
a Web site for the State of Colorado Division of Wildlife. It
was a small ASP.NET intranet project titled LAR (Land
Acquisition Request) to be written in VB.NET with the data
stored in SQL Server. Other than some client-side validation,
all application logic was placed in code-behind modules.
After I finished the application, I ran the FMS Total .NET
Analyzer against my code and was shocked at what I saw. Mind
you, I started this project with no formal .NET training. I
relied on my classic VB experience, a .NET how-to book, and the
modern miracle of IntelliSense. The results of the analysis
suggested 2,206 issues with my code. Sure, I may be a .NET
novice, but that seemed somewhat high for a Web application with
only 18 pages. That's when I discovered the purpose of the Rule
Editor.
You'll notice that Figure 1
displays some examples of the kinds of issues identified by
Total .NET Analyzer?"things like Boxing, Unused Code, Option
Strict Not Set, and so forth. I discovered that many of these
issues weren't important to me and I didn't want to see them in
the list. This is where the Rule Editor comes in. The Rule
Editor, shown in Figure 2, allows you to filter the
output list for only the types of issues you want to view,
making the list more manageable.
Figure 1
Figure 2
One issue that was identified in about 80 places was a
violation of what's called the NameLength rule. This issue often
turned up in VS.NET-generated code, such as in the Page_Load
event handler, where variables are sometimes given single
character identifiers. In other cases, it was my variable
declarations that were flagged as needing attention.
ByVal e As System.EventArgs
Dim i As Integer
Naturally, this confused me, as I saw nothing wrong with the
preceding code, nor did the creators of Visual Studio .NET,
since some of the suspect code was theirs. Using a single
character, such as i or x, is an old VB habit that seemed
perfectly acceptable to me. Accordingly, I turned to the FMS
Total .NET Analyzer Help file to find out what the problem was.
Clicking on the issue once loads the module with the offending
code and advances you to the line containing the violation. Once
selected, clicking the Information button in the toolbar loads
the Help file page that explains the issue. The Help file
provided the following advice for the NameLength rule:
Lengthen variable names to describe the purpose of the
variable.
Remarks
In general, variable names should be between 4 and 32
characters long, and should describe the purpose of the
variable. Short variable names often don't identify the
purpose of the variable, and make your code difficult to
understand, debug, and maintain.
Total .NET Analyzer identifies variables with names
shorter than the minimum length specified in the Rule
Editor. The default minimum length for variable names is
3, but you can change this number as desired.
Resolution
In order to make your code easier to read and
understand, you should rename your variable to be more
descriptive.
See Also
Naming Conventions
As you might imagine, I didn't consider this a serious issue
for the performance or readability of my code. The same applies
to another issue that popped up 350 times, related to the rule
named Hungarian. It seems that in Visual Studio .NET, Microsoft
has changed its standard for naming conventions, and no longer
recommends Hungarian notation. While that's good to know, I
didn't want to be bothered with these issues while reviewing my
code, so I used the Rule Editor to disable these rules and ran
the Analyzer again, removing these issues from consideration.
Up to this point, I've mostly just explained how Total .NET
Analyzer works, and in fact, the interface is quite simple with
very few functions:
? Click Analyze to analyze your code.
? Click Rule Editor to filter the issues list.
? Click the Information button to understand why the code
was flagged as an issue.
That's all there is to using this utility. It's completely
integrated into the Visual Studio environment, with dockable
windows that may be hidden just like other VS windows (see
Figure 3). So, if it's so simple, where's the bang for the
buck?
Figure 3
Getting down to business with Analyzer
The real value of FMS Total .NET Analyzer can be summed up in two
words: best practices. What I discovered was that while my classic VB
style code was supported, it wasn't always the way of .NET. Just because
your code compiles doesn't mean it's correct. Figure 2 shows references
to issues under the category VB Legacy, identifying practices to avoid
and instructing you on the Visual Studio .NET equivalents.
By reviewing each of the Total .NET Analyzer rules violated
and reading the associated Help files, I was able to generate
code that looked more like a .NET project than a classic VB
project. For example, string concatenation is well known to be
inefficient in Visual Basic. The StringAddition rule identifies
instances where you'd be better off using the new .NET
StringBuilder class. The following example, modified to fit in
the printed page, shows the VB .NET way to create a concatenated
string:
Dim sb As System.Text.StringBuilder
sb = New System.Text.StringBuilder("SELECT * ")
sb.Append("FROM ParcelQuestionPage07")
sb.Append("WHERE ParcelID=")
sb.Append(intParcelID.ToString)
By reading the Help file associated with each violated rule,
I learned, among other things, about boxing, variable typing,
and effective use of the new style error handling. The Analyzer
utility found unused variables and functions, identified empty
Catch statements, and revealed other important irregularities in
my code, which I had overlooked. After reviewing each issue, I
was able to deliver my code to the client with confidence. It
was my first .NET project, but my code looked like that of an
experienced .NET developer.
Is FMS Total .NET Analyzer for you?
I've always been a fan of FMS utilities, and I was excited to see
their .NET line when it came out. Personally, I wasn't disappointed by
Total .NET Analyzer and I highly recommend it. If you're new to .NET and
you do well learning new technology on your own, as I do, this tool will
be invaluable for its best practice advice. For me it was like taking an
advanced self-study course in VB.NET. If you're an expert, you'll still
find it helpful to have another "set of eyes" checking your code for
errors and performance issues. In my opinion, this is a great utility
that's worth the price of admission.
Back to Main Reviews Page
|