| < Day Day Up > |
|
VS .NET was designed from the start to be extensible, and many utility vendors have taken advantage of this extensibility. In the remainder of this chapter, I’ll look at a selection of ways to make your time writing code with VS .NET more productive (or more fun), and to improve the quality of the code that you write in this environment. This isn’t intended to be a comprehensive survey by any means. I’m going to single out some add-ins that I’ve used myself and that show the range of capabilities that an add-in can bring to VS .NET.
Note | This chapter includes information on some general-purpose add-ins. You’ll also find more specific add-in coverage in other chapters. For instance, I talk about NUnitAddin in Chapter 5, “Preventing Bugs with Unit Testing,” and the CodeSmith add-in in Chapter 8, “Generating Code.” |
Some add-ins exist that let you add a single missing function to the VS .NET IDE. For example, suppose you want to know how many lines of code you’re written in your project. You could open up each code module separately, use Ctrl+End to get to the last line, note the line counter in the VS .NET status bar, and add up all the individual numbers using a spreadsheet—or you could download and install the free Project Line Counter add-in from WndTabs (www.wndtabs.com/plc/). This add-in has the simplest interface possible: a single toolbar containing a single button. Load your project, click the button, and you’ll see a report similar to the one in Figure 6.6.
Figure 6.6: Project Line Counter
Of course, developers can seldom stop at a single feature, and the developer of Project Line Counter is no exception. In addition to displaying information on your project, this add-in lets you filter the report to show only information from a single project in your solution, or to export the report to a comma-separated value (CSV) or XML file for further analysis.
Note | The sharp-eyed reader will notice that Figure 6.6 contains all of the various projects that make up Download Tracker, including all of the different code layers and the test projects. To make it easier to work on Download Tracker without having multiple instances of VS .NET open, I created an empty VS .NET solution and then added all of the individual projects to this solution. |
Before moving on, it’s worth taking a moment to think about when it’s useful to know the number of lines of code in a project. Lines of code, sometimes referred to as LOC, is one of the earliest metrics developed for managing software projects. Over the past several decades, LOC has been largely discredited as a useful measure, for two reasons. The first problem is the explosion in computer languages. A single line of code in one language might be equivalent to hundreds of lines of code in another language. For example, writing code in C++ is often more verbose than writing the same code in VB, even when the functionality is identical. Second, even within a language different coders can use different numbers of lines of code for the same expression. Consider this snippet of code from Download.cs:
public string ProductName { get { return _ProductName; } set { _ProductName = value; } }
This code would work just as well written like this:
public string ProductName { get { return _ProductName; } set { _ProductName = value; } }
So, is it 11 lines of code or 6?
But the fact that LOC varies between languages and developers doesn’t make it perfectly useless. If you compare LOC between your own projects written in the same language, it’s a reasonable way to confirm your own sense of which project is larger and which modules have involved the most effort. Keeping an eye on the relative percentage of comment and blank lines can also help you pick out modules that are underdocumented (or overdocumented, though that’s much rarer).
Another simple and free add-in is QuickJump.NET (www.codeproject.com/dotnet/quickjump_net.asp). With this little tool involved, you can click Alt+G and get a window showing all of the members in the current class. Type a few letters to filter the list, and you can jump right to the applicable declaration. Figure 6.7 shows this add-in in action.
Figure 6.7: QuickJump.NET
QuickJump.NET illustrates another reason for installing an add-in: Sometimes functionality is already present in VS .NET, but it doesn’t work the way you would prefer. If you want to find a particular member in the current class, you can select it from the Members drop-down list at the top of the code editor. Alternatively, you can enter incremental search mode by pressing Ctrl+I and then typing the start of the member you’re looking for until the search highlight finds it (press Enter to exit from incremental search mode). For a third alternative, you could open the Class View window and expand the tree to find the member that you want, and then double-click it. However, some people prefer the convenience of a list of members in a separate window, and for those people this add-in exists.
VS .NET is a good platform for writing code, but sometimes it leaves a bit to be desired when it comes to managing large projects. For example, suppose you want to know where you’ve used a particular property. This is essential knowledge when you’re thinking about changing the property’s data type. You could just make the change and then build the project to see what breaks. But a better solution (at least for Visual Basic .NET and C# projects) is Total .NET XRef from FMS (www.fmsinc.com/dotnet/xref/index.asp). At $199, this tool keeps track of the structure of your projects. Place your cursor in any identifier, click the XRef button, and you’ll get a window listing every place that identifier is used. You can see files, classes, lines, members, and even a preview of the usage. A single click takes you to the definition of the object, or you can double-click to see any usage line. Besides making it easy to navigate to everywhere that a member is used, Total .NET XRef, shown in Figure 6.8, is a good tool for quick-and-dirty impact analysis.
Figure 6.8: Total .NET XRef
Speaking of FMS, you might also check out Total .NET Analyzer (www.fmsinc.com/dotnet/Analyzer). This $499 add-in leverages the same parser as Total .NET XRef to look over your code and warn you about deviations from best practices and likely errors. These range from using string concatenation where a StringBuilder would be a better choice, to unused code, to performance issues, to violations of generally accepted naming standards. All of the recommendations show up in a dockable window (shown in Figure 6.9), and you can click on any of them to go right to the line of code that the tool doesn’t like. You can also customize the rules list to a certain extent, though there’s no way to add your own rules to the product.
Figure 6.9: Total .NET Analyzer
Note | Another tool that can help check the quality of your source code is FxCop, a stand-alone utility from Microsoft. I’ll talk about FxCop in Chapter 7, “Digging into Source Code.” |
The Total .NET products (as well as other add-ins from other vendors) take advantage of a key feature of the DTE object model for add-ins. The add-in has access to every bit of code that you have loaded into a project. This makes it easy to catalog, cross-reference, analyze, or even modify code from an add-in.
Comparing Figure 6.6 with Figure 6.9, you’ll see that Total .NET Analyzer found 257 issues in 1500 lines of code. Isn’t that rather a lot? No, not really. I ran Analyzer with all of its rules turned on, including style rules (such as using camel case for variables) that I don’t personally agree with. Also, there’s a limit to how much intelligence you can build into this sort of static code analysis. For example, the tool properly suggests replacing literal strings with constants or resources as a general rule. But this rule fires multiple times when I build a Structured Query Language (SQL) statement using code like this:
cmd.CommandText = "INSERT INTO [Downloads]([ProductName], " + "[FileName], [DownloadDate], [Version], [Description], " + "[Rating], [Size])" + " VALUES('" + d.ProductName + "', '" + d.FileName + "', #" + DateTime.Now.ToShortDateString() + "#, '" + d.Version + "', '" + d.Description + "', '" + d.Rating + "', " + d.Size + ")";
There’s not a lot of point to using string constants for strings that are used only once or to using resources for SQL strings (which, by definition, are never localized). Perhaps someday code analysis tools will be available that don’t require thought on the part of the developer, but I haven’t seen them yet.
TECHNOLOGY TRAP: The Ten-Ton IDE
Obviously, there are lots of VS .NET add-ins out there, at a variety of prices and with a variety of functionality. VS .NET has no particular limit on the number of add-ins that you can have loaded at one time. Many developers are a lot like magpies. We tend to collect every shiny thing that comes our way. Do this with .NET add-ins, and you may someday end up with a copy of VS .NET that has 30 or 40 add-ins installed.
If (like me) you’re one of the developers with that tendency, try to restrain yourself. Having too many add-ins loaded at once can cause some problems with VS .NET. Chief among these is that startup time gets longer and the memory taken by the IDE increases, which can hurt your overall system performance. Paradoxically, too many laborsaving devices can make more work for you if you have to wait for the IDE to catch up. Also, the more add-ins you load, the greater the chance that they’ll conflict in the shortcut keys they assign to various functions, at which point it becomes difficult to know which key will do what.
The best solution to this problem is to develop an explicit process for evaluating add-ins. Rather than installing an add-in and then just forgetting about it, install the add-in and set a reasonable period of time (a week works well for me) to evaluate it. Put a reminder in your Outlook tasks to make sure you remember when the week is up. Then think back over the past week and then decide whether the add-in really saved you time, made your code better, or had other benefits. If not, then uninstall it rather than just letting it sit there unused.
VS .NET add-ins can have much more radical effects than just adding a new toolbar or window. For example, they can completely replace the built-in editors. Here are two products that do just that.
CodeWright for VS .NET (www.codewright.com/cwnet/default.asp) merges the CodeWright programmer’s editor directly into the VS .NET IDE. This lets you use CodeWright’s keystrokes and color syntax (among other features) in your .NET source files, as well as making all of CodeWright’s other high-end features (like the CodeMeeting chat window, which lets you edit documents collaboratively) available within the .NET interface. Especially if you’re already a CodeWright user, spending $149 for this product will likely boost your productivity in VS .NET substantially. While the native VS .NET editor is good, it doesn’t have the depth of keyboard tools and shortcut customization of a real top-end programmer’s editor.
For XML files, you can get a similar plethora of tools by spending $999 for XMLSPY Enterprise Edition (www.altova.com) and then downloading the free package to integrate it with .NET. No more will you have the basic Microsoft XML-editing user interface for XML files in your .NET solution. Instead, XMLSPY’s multiple views, debugging capabilities, and flexible interface will take over XML-editing duties. Given the cost, this probably makes sense only if editing XML is a frequent task for you, but if it is, this is a great way to merge two best-of-breed tools.
Some add-ins are so all-encompassing that it almost seems silly to refer to them as add-ins. Products in this category include CodeSMART, Rational XDE, and Compuware DevPartner Studio.
CodeSMART 2003 for VS .NET ($189 from www.axtools.com/index.htm) is a sort of a Swiss Army knife of add-ins. In contrast to the single-purpose add-ins like Project Line Counter, CodeSMART does many things and does most of them very well.
It’s unlikely that any developer will use all the functionality here, but you’ll find your own favorites. One of mine is the Code Explorer, shown in Figure 6.10. It’s a relatively easy concept to understand: Take the existing Solution Explorer, and tack the Class View functionality on to it. So you can drill from solution to project to class—and then on down into members. Each level maintains all of its existing context menu functionality, and then gains a bit more. For instance, the VS .NET Class View will let you quickly go to the definition of a member; Code Explorer also lets you go to the start or end of the member, or highlight it in code, or add it to the Workbench.
Figure 6.10: CodeSMART Code Explorer
The Workbench is another CodeSMART tool window. It’s a collection of nodes pulled off the Code View and kept as a flat list. This is a great way to focus on a subset of your project and to easily jump back and forth among the areas of your code that you’re currently interested in.
Then there’s the Find Type Reference facility, which helps you see where a particular type is used anywhere in your code; think of it as cross-reference on-the-fly. There are some other find and replace extensions as well, including the ability to search through all the files in your solution with one click (which Microsoft inexplicably left out of VS .NET).
CodeSMART also includes a number of code builders that range from simple (inserting a property with a particular name and return type, or inserting error trapping) to complex (implementing an entire interface). For other code construction tasks, CodeSMART includes an AutoText tool that can expand a few letters into an entire code snippet. There’s also a sort of code repository to manage other chunks of code.
Code reformatting is another strength of CodeSMART. You can sort procedures in a class by type or name, split and otherwise automatically reformat lines, and even manage XML comments in VB .NET applications. CodeSMART includes a dialog box that lets you set the Name and Text properties of any control when you create the control, tasks you’ve probably done a million times in the Properties window by now.
Even more ambitious is Rational XDE (more formally IBM Rational XDE Developer .NET Edition v2003.06). XDE makes the development environment even more complex by bringing modeling into the picture. With XDE installed, you continue to develop software inside the VS .NET shell. But now, in addition to writing code, you can design code with Unified Modeling Language (UML) diagrams (or with more abstract models, for that matter).
Key to making all this work is forward and reverse engineering support, as well as model-to-code synchronization. What that means is that you can make a change to your code, and XDE will update your model—or vice versa. If you’ve already got a project full of code, bringing it into the XDE world is as simple as loading your project and telling it to generate the model. Databases, too, can be engineered in both directions. Figure 6.11 shows a UML diagram of some of the Download Tracker classes, generated by XDE, together with the XDE Model Explorer and some of the options that it offers for building models.
Figure 6.11: UML model generated by Rational XDE
XDE also supports repositories of patterns, so you can create reusable software assets and share them across your enterprise. It also supports runtime for trace sequence diagrams. Basically, you tell it that you want it to graphically monitor what’s going on, and XDE builds a sequence diagram as the classes in your application interact in real time. It’s cool to watch this process in action as your classes talk to one another. The sequence diagrams can be filtered easily to let you concentrate on the interactions you’re interested in, making them a good debugging tool as well as a documentation tool.
Note | For more information on UML and patterns, see Chapter 2, “Organizing Your Project.” |
All this power comes at a cost in both complexity and money. You’ll need to know the basics of UML before trying to use XDE, and you need to allow ample time to come up the product’s learning curve (there’s extensive documentation to help with that). As for the money, a single-user license with a year of support will set you back about $3500, putting it out of the range of projects like Download Tracker. But it’s good to know about the high-end tools if you’re in a setting where such things make sense on a corporate level.
While XDE is directed at the architect, DevPartner Studio is aimed squarely at the developer. For $1495, it adds a number of high-end debugging and tuning capabilities to VS .NET. For starters, there’s the Code Review facility. This is a rules-driven engine designed to help you locate dangerous parts of your code before they break down. It’s something like Total .NET XRef, only with enhanced capabilities. In addition to warning you about dangerous code (and offering suggestions for fixes), it will also help you enforce naming conventions and calculate complexity for your methods. You can also edit and customize the rules used for the analysis, filter the results, and suppress rules in a given project.
DevPartner also contains an error-detection feature, which lets you run your application while DevPartner keeps an eye on the internals. This feature can detect COM API errors and memory leaks, deadlocks and unsafe threading code, and problems with dispose and finalize, among other issues.
DevPartner’s code coverage analysis capabilities help you make sure that you’re testing all of the code that you write. Like most of DevPartner’s features, this one is pretty unobtrusive. Turn it on, run your application as you normally would, and exit the application. You’ll get a code analysis report that shows which methods were called, what percent of lines of code were executed, and so on. Double-click a method and you get a color-coded view of the code showing exactly what was (and wasn’t) exercised by your tests. Even better, if you’re dealing with a distributed application, you can perform a joint and simultaneous code coverage analysis of both client and server pieces.
Runtime memory analysis and runtime performance analysis provide you with two other ways to track what’s going on in a running application. The memory analysis will show you which methods used the most memory, where temporary objects are allocated, and so on. You can also force a garbage collection (GC) while the application is running—useful in cases in which you’re not sure whether the GC process is part of the problem. Performance analysis will get you execution times, call graphs, and much more information. Both of these modes of analysis offer flexible ways to view their information, which is useful because there’s so much information. Figure 6.12 shows a DevPartner memory analysis of the Download Tracker application in action.
Figure 6.12: Analyzing memory usage with DevPartner Studio
Note | For the definitive list of VS .NET add-ins (and other .NET utilities), visit the SharpToolbox site at http://sharptoolbox.madgeek.com/, which is approaching 350 listed tools as I write this. |
| < Day Day Up > |
|