This Issue Sponsored By
ASP & Visual Studio Connections Conference
In This Issue
1. Developer .NET Perspectives
2. New and Improved
1. Developer .NET Perspectives
Before I get to this week's topic, I want to take a moment to let you know that I'm not oblivious to the latest and greatest from Redmond. Visual Studio 2005 beta 1 (formerly code-named Whidbey) has been released. The full version of Visual Studio 2005 is available, as are the beta 1 versions of six Visual Studio 2005 Express packages. These packages target specific subsets of capabilities. For example, SQL Server 2005 Express, which is based on the Microsoft SQL Server Desktop Engine (MSDE), provides database support. SQL Server 2005 Express is free and compatible with the other five low-cost Express packages, which focus on one of two areas: Web development or desktop development. On the Web side, there's Visual Web Developer 2005 Express, a language-independent tool for building Web applications and services. On the desktop side, there's a different Express package for each .NET language. Apparently, unlike Web developers, desktop developers are supposed to use only one language.
As you probably know, Visual Studio 2005 is built on Microsoft .NET Framework 2.0. In my next column, I'll introduce to this new .NET Framework version. After all, the release of Visual Studio 2005 beta 1 means that the release of .NET Framework 2.0 is less than 365 days away.
In this column, I want to introduce you to FxCop, an automated standards checker available from the Got Dot Net Web site (http://www.gotdotnet.com/team/fxcop). Automated standards checkers are tools that let you quickly analyze code for common mistakes and poor programming practices.
Lately, FxCop has been getting more attention and supporters. Some developers love this tool and accept what it tells them as gospel. However, I'm not yet one of its biggest fans, not because of technical problems, but because I don't agree with blindly accepting any tool's recommendations. I don't oppose apply programming standards, and I like that FxCop lets me customize the standards it applies. Coding standards don't just make code easier to maintain. They also reduce errors, and automated standards checkers like FxCop make it easier to enforce those standards. However, I see similarities to my experiences from a decade ago. Back then, the company I worked for introduced an automated standards checker to check some code written in a now obsolete development language. Although it did some things well, there were some problems. Before I share that experience, though, let's look at FxCop and discuss some of its good and bad points.
A Look at FxCopFxCop comes with a set of customizable rules. Although the rules are a bit cryptic, they're applied by a very powerful engine. As far as code analysis engines go, FxCop's engine is top of the line. In fact, Microsoft uses this engine internally. As for the rules, they'll get better with time as they go through the dog fooding process. For those of you unfamiliar with dog fooding, it's a reference to using your own software, with all its bugs and design problems, internally to find out how well it really works. Microsoft employees routinely use beta versions of the company's applications to thoroughly test them before their formal release. Given that FxCop is oriented toward code development, it's getting lots of internal use at Microsoft.
In the past, automated standards checkers were used to check source code almost exclusively. As a result, most standards checkers mainly focus on finding problems in source code. FxCop is different than most standards checkers in that it checks managed assemblies rather than source files. There are some advantages and disadvantages to this approach:
- On the plus side, checking the assemblies instead of the source files means that .NET developers only need one version of the tool to handle Visual C# .NET, Visual Basic .NET, and Visual C++ .NET assemblies. Because Microsoft's developers don't need to create a custom set of rules for each language's syntax, they're able to use one version of FxCop, thereby reducing the time and cost needed to develop the tool. In addition, because FxCop targets the assembly, it can look for problems that exist in the runtime environment. In other words, it doesn't just find spelling errors. It finds much more important problems, such as those related to memory management and security. To facilitate these types of checks, FxCop is built on a set of interchangeable rules. You can import, enable, and disable individual rules that the FxCop engine uses to evaluate your assembly.
- On the minus side, because FxCop runs against compiled code rather than source code, it doesn't actually pinpoint the location of the problem in the source code. Although FxCop can, in most cases, tell you in which source file the problem is, it can't tell you where in that source file. In addition, because FxCop only loads the target executable, it might not know where to find the source files. The result is that when FxCop attempts to provide a link to a project's source files, it assumes that you keep the project in the default location under the \My Documents\Visual Studio Projects directory. Unfortunately, many developers have slightly more complex directory structures. Although FxCop has excellent links to pages that define problems, it leaves finding and addressing the problems up to the developer. I expect this situation will change over time, as the tool continues to be enhanced and integrated with Visual Studio .NET.
- http://www.devconnections.com
Announcements
(brought to you by SQL Server Magazine)- Get 9 Years of Windows & .NET Magazine Network Content
Introducing the Windows & .NET Magazine Network VIP Web site/Super CD subscription. This all-inclusive package not only provides online article access to all network publications, a print subscription to Windows & .NET Magazine, and exclusive access to our banner-free VIP Web site, but it also now includes SQL Server Magazine content. Subscribe today!
- https://secure.pentontech.com/nt/vip/index.cfm?PromoCode=wvep2747du
- Amaze Your Coworkers with Your SQL Server Smarts
SQL Server Magazine delivers quality content relevant to all SQL Server professionals. Choose from a library of helpful articles, interactive discussions, savvy advice, and time-saving tips that focus on such hot topics as SQL Server 2005, backup and recovery, security, and much more. Subscribe today and get a free System Table Map Poster!
- https://secure.pentontech.com/nt/sql/index.cfm?promocode=psep2147su
Events Central
(A complete Web and live events directory brought to you by Windows & .NET Magazine: http://www.winnetmag.com/events )- Get Smart! Evaluate Your Options in the Entry-Level Server Market
Comparing the options in the server market, including the decision to purchase an OEM-supplied server versus building your own, can be a daunting task. This free Web seminar provides an introduction to entry-level servers, evaluates the current market of entry-level servers, and assesses the value of vendor-supplied service and support. Register now!
- http://www.winnetmag.com/seminars/entrylevelservers/index.cfm?code=0628emailannc
3. New and Improved
- Testing Tool for .NET Applications
Empirix released the e-TEST suite, a native .NET application testing solution. With the e-TEST suite, people don't need to be .NET experts to test .NET applications. Specific .NET testing features include ASP.NET, WinForms, and Web services testing. The solution includes software that integrates the e-TEST suite into Visual Studio .NET. You can download a free trial version. Contact Empirix at 781.993.8500 or 866-228-3781.
- http://www.empirix.com/dotnet
Contact Us
- About Developer .NET Perspectives -- [email protected]
- About the newsletter -- [email protected]
- About technical questions -- http://www.sqlmag.com/forums
- About product news -- [email protected]
- About your subscription -- [email protected]
- About sponsoring an UPDATE -- contact Kate Silvertooth ([email protected])
This email newsletter is brought to you by Windows & .NET Magazine, the leading publication for IT professionals deploying Windows and related technologies. Subscribe today.
- http://www.winnetmag.com/sub.cfm?code=wswi201x1z
View the Windows & .NET Magazine Privacy policy at
- http://www.winnetmag.com/aboutus/index.cfm?action=privacy
Windows & .NET Magazine, a division of Penton Media, Inc.
221 East 29th Street, Loveland, CO 80538
Attention: Customer Service DepartmentCopyright 2004, Penton Media, Inc. All Rights Reserved.
Like most automated standards checkers, FxCop is aggressive with regard to naming standards. In my code, I consistently use Hungarian notations for local variable and parameter names. Buried away in Microsoft's .NET naming standards is a statement that Hungarian notation shouldn't be used in .NET projects. (The .NET naming guidelines are available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconNetFrameworkDesignGuidelines.asp.) Thus, when I use FxCop, it encounters a lot of "errors" in my code. In reality, they aren't errors but rather nonconformities. I'm not expecting Microsoft to change the default rules that ship with FxCop so that it has a new default rule that allows Hungarian notation. My point is that when you use FxCop or any other automated standards checker, you're essentially following someone else's opinion of what is best for your code. Be prepared to think intelligently about how you implement the tool's recommendations.
Blindly Applying RecommendationsBlindly applying recommendations that don't help with the actual maintenance of your code can cause as many problems as it solves. Let's take a look at a real-world example.
As I mentioned previously, I used a standards checker many years ago. The other project developers and I had to follow strict naming conventions for this million+ line system to keep different functional areas from colliding. However, when we interchanged data with another portion of the system, we typically tracked that data by the originating namespace, especially if the data would be returned, because in some cases, we wanted to be certain not to modify that data before it was returned to the originating namespace.
This system had already been around for years when we brought in an automated standards checker, which was programmed to recognize our namespaces. The checker often flagged areas in which, for example, we used "i" as a loop-control variable name. Of course, "i" wasn't associated with a namespace. (By the way, if you're unfamiliar with the origin of "i" and "j" as common loop-control variable names, feel free to email me for an explanation.) The standards checker also flagged those areas in which we intentionally used another functional area's prefix for the variables in our source files so that we could track that data as I described above.
As experienced developers, we recognized these flags as noise, but unfortunately the standards checker's results were reviewed by some managers who didn't understand the difference between noise and actual problems. Namespacing-related flags tend to fall into the noise category; however, to a manager who is looking to reduce the number of "problems" by 50 percent, they're prime targets.
So, the managers had some junior developers work to change the names of the "i" loop-control and similar variables; implementing and testing these changes cost the company extra money. The managers also had the junior developers change the names of the variables that had another area's prefix, which cost the company even more money.
In about a year, it came time for the next release. This release was worked on by some newly hired developers--developers who had no idea that a variable now in their namespace contained data that was really the property of another functional area. As I'm sure you can surmise, the confusion resulted in a new set of additional costs.
Now, don't get me wrong. Using the automated standards checker wasn't a failure. It did catch some legitimate errors. And there were many of us with enough experience to be able to explain the noise--and managers who were willing to listen--to keep major portions of the project from being needlessly changed. In addition, because we told the standards checker's developers about some of the noise we experienced, future releases of the automated tool accounted for it. Similarly, FxCop lets you report noise. FxCop is only at version 1.3, so it's still under development and Microsoft is still enhancing the tool in ways that will make it more valuable.
The bottom line is that you shouldn't just blindly accept the recommendations of FxCop or any other automated standards checker. If you do, you might be changing your code needlessly, adding time and expense to your projects. The goal of FxCop, as stated by Microsoft, is to provide a tool that let's you get a report related to items in your code you should question. A confidence level is associated with each potential problem for good reason: The automated checker still can't account for everything that an experienced developer can recognize.
Sponsor: ASP & Visual Studio Connections Conference
Microsoft, MSDN Magazine, and Tech Conferences come together November 7-10 in Las Vegas, NV to bring Microsoft developers a conference that will rock the industry! Be among the first to uncover what INDIGO, Microsoft's code name for the next generation distributed application technology, is all about. Attendees will receive the latest build of Visual Studio 2005 and a beta copy of SQL Server 2005. Register now and attend sessions at SQL Server Magazine Connections FREE!
