|    Product Review: FMS Total 
							.NET AnalyzerVS.NET, Danny J. LesandriniLooking 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.12/2003
				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.EventArgsDim 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 AnalyzerThe 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   |