Last spring I co-authored this book, Practical Guidelines and Best Practices for Microsoft Visual Basic .NET and Visual C# Developers, arguably the longest title in Microsoft Press's history. The book is a reasoned list of guidelines that all .NET developers should follow, actually is by far the largest collection of its kind you can find anywhere. It covers language syntax, memory usage, Windows Forms and ASP.NET applications, security, and more. Unlike most other similar collections, though, we clearly divide the "rules" in guidelines (naming guidelines, comment usage, etc.) and best practices. The difference is subtle but important: most guidelines are primarily a style matter, whereas best practices impact the scalability, the speed, or the robustness of your application. This means that our guidelines are arbitrary and in fact we often offer alternate rules and clearly explain the pros and cons of each style. You can learn more about the principles we used in the book's Introduction and in John Robbins's Foreword. (Unlike most foreword writers, John actually read each and every page in the manuscript and gave us some great advice about improving it.) Or click the figure to jump to the book's home page, where you can read three sample chapters and download the book's source code. Today I have uploaded a 30-page Word document that contains a summary of all the rules covered in the book, orderly grouped by topic and with a reference where in the book each rule is explained. You can edit this document as you see fit, delete or edit the guidelines you aren't interested in, and so forth. We routinely use this document in internal code reviews or when we consult at customers' places, so we hope it will be useful to you as well. P.S. You must register to access this material. We swear we'll never send you anything that vaguely resemble spamming, just 100% technical contents!

Consider the following code, that converts all the elements of an Int32 array into the corresponding hex value:

' VB
Dim intArray() As Integer = {4, 6, 9, 10, 99, 233, 34, 88, 189}
Dim hexArray(intArray.Length - 1) As String
For i As Integer = 0 To intArray.Length - 1
   hexArray(i) = intArray(i).ToString("X")
Next

// C#
int[] intArray = {4, 6, 9, 10, 99, 233, 34, 88, 189};
string[] hexArray = new string[intArray.Length];
for ( int i = 0; i < intArray.Length; i++)
{
   hexArray[i] = intArray[i].ToString("X");
}

The question is: how can you make this code more concise in .NET 2.0? The first answer that might come up is to use the Array.ConvertAll method together with a C#'s anonymous method:

string[] hexArray = Array.ConvertAll<int,string>(intArray, new Converter<int,string>(
   delegate(int n) { return n.ToString("X");}));

Actually, you can write even more concise code if you remember than the Microsoft.VisualBasic library already contains the Hex method, which matches the signature of the Converter<int,string> delegate. Using this method and delegate inference, you can shrink the code to:

' VB
Dim hexArray() As String = Array.ConvertAll(Of Integer, String)(intArray, AddressOf Hex)
// C#
string[] hexArray = Array.ConvertAll<int,string>(intArray, Microsoft.VisualBasic.Conversion.Hex );

I am certain that few C# developers will use this trick, but I thought it was worth mentioning. (Of course, you must add a reference to the Microsoft.VisualBasic.dll assembly if you work with C#.) The key idea, however, is that in some cases you don't need to write an anonymous method to accomplish a given task, because often you can find what you're looking for in the .NET Framework. For example, you can display all the elements of an array in the Console window with just one statement:

' VB
Array.ForEach(hexArray, AddressOf Console.WriteLine)
// C#
Array.ForEach(hexArray, Console.WriteLine);

There are many other methods in the VB library that you can use to convert all the elements of an array or a generic List, including UCase, LCase, LTrim, RTrim, and Trim.

One of the .NET Framework features that fascinate me most is regular expressions, which I often use to simplify and speed up my applications. Well, at least this is what I believed until some time ago, when I was busy writing the forthcoming Programming Microsoft Visual Basic 2005: The Language (due in mid-January). This book is a core reference on the VB language and includes a section on the LIKE operator, which in recent years a overlooked in favor of regexes. I (mistakenly) assumed that the Like operator internally used the Regex classes, therefore surely it would have been slower. After all these years, I should have learned that I should never jump to conclusions without testing and benchmarking my code accurately. .

Let's say that you must check that a string has 9 characters, the first of which must be an uppercase "A" and the last four chars must be digits. This is how you'd perform this test with a regex:

Dim re As New Regex("^A....\d\d\d\d$")

and here's the version that uses the Like operator:

If teststring Like "A????####" Then Match = True

Surprise! Putting this code in a loop (but leaving the creation of the regex out of the loop) and using a string that makes the test succeed (e.g. "ABCDE1234"), the Like operator is about 4 times faster than the regular expression. Not bad, uh? But the biggest surprise came when I benchmarked the same test based on methods of the System.Char class exclusively:

If teststring.Length = 9 AndAlso teststring.Char(0) = "A"c AndAlso Char.IsDigit(teststring.Char(5)) Then
   AndAlso Char.IsDigit(teststring.Char(6)) AndAlso Char.IsDigit(teststring.Char(7))
   AndAlso Char.IsDigit(teststring.Char(8)) Then match = True

Despite of its length, this last test is about five times faster than the Lik operator, and therefore about 20 times faster than the regexes! The gap gets closer if using compiled regexes, but the System.Chars approach is by far the fastest of the lot.

The bottom line: (1) if you write VB code, use the Like operator instead of regexes if the condition isn't too complex, and (2) regardless of the language you work with, if you really want the highest performance, use the methods of the String and Char types, if the search operation isn't too complex.

Every now and then I get an email from a reader or a customer, who asks for clarifications on object finalization and disposing. As far as I know, the best article on this topic is this essay by Joe Duffy. It's over 25-page long, covers both .NET 1.1 and 2.0, and includes comments from gurus such as Jeffrey Richter e Chris Brumme. This is easily the definitive article on this topic and I urge you to read it if you haven't already.

The Dispose-Finalize pattern is objectively a complex matter. However, in most cases it can be simplified significantly if you use the following approach: (1) the class with the Dispose/Finalize method should wrap only one single unmanaged resource, and (2) this finalizable class should be private and nested inside another disposable (but not finalizable) type. The outer class is the only class that can use the finalizable class.

This simple trick enables the GC to immediately release all the memory used by the wrapper (disposable) class even in the worst case - that is, if the client code omits to invoke the Dispose method - and simplifies the structure of the type that uses the unmanaged resource. A listing is worth one thousand words, thus here is the C# version of what I mean:

// the class that clients use to work with the unmanaged resource
class WinResource : IDisposable
{
  // private field that creates a wrapper for the unmanaged resource
  private UnmanagedResourceWrapper wrapper = null;
  // this is true if the object has been disposed of
  bool disposed = false;

  public WinResource(string someData)
  {
    // allocate the unmanaged resource here
    wrapper = new UnmanagedResourceWrapper(someData);
  }

  // a public method that clients call to work with the unmanaged resource
  public void DoSomething()
  {
    // throw if the object has been already disposed of
    if ( disposed )
      throw new ObjectDisposedException("");

    // this code can pass the wrapper.Handle value to API calls.
    // ...
  }

  public void Dispose()
  {
    // avoid issues when multiple threads call Dispose at the same time.
    lock ( this )
    {
      // do nothing if already disposed of
      if ( disposed )
        return;
      // dispose of all the disposable objects used by this instance
      // including the one that wraps the unmanaged resource
      // ...
      wrapper.Dispose();
      // remember this object has been disposed of
      disposed = true;
    }
  }
 
  // the nested private class that allocates and release the unmanaged resource
  private sealed class UnmanagedResourceWrapper : IDisposable
  {
    // an invalid handle value, that the wrapper class can use to check
    // whether the handle is valid
    public static readonly IntPtr InvalidHandle = new IntPtr(-1);

    // a public field, but accessible only from inside the WinResource class 
    public IntPtr Handle = InvalidHandle;

    // the constructor takes some data and allocates the unmanaged resource (eg a file)
    public UnmanagedResourceWrapper(string someData)
    {
      // this is just a demo...
      this.Handle = new IntPtr(12345);
    }

    // the Dispose method can be invoked only by WinResource class
    public void Dispose()
    {
      Dispose(true);
      GC.SuppressFinalize(this);
    }

    // the finalizer
    ~UnmanagedResourceWrapper()
    {
      Dispose(false);
    }

    // This is where the unmanaged resource is actually disposed of.
    // Notice that it takes an argument only for compliance with .NET coding standards
    // but the disposing argument is never used, because in all cases this class
    // can access and release only the single unmanaged resource it wraps.
    private void Dispose(bool disposing)
    {
      // exit now if this object didn't completed its constructor correctly
      if ( this.Handle == InvalidHandle )
        return;
  
      // release the unmanaged resource 
      // eg. CloseHandle(Handle);
      
      // finally, invalidate the handle
      this.Handle = InvalidHandle;
    }
  }
}

Notice that, if the unmanaged resource must interact with other fields, this interaction should be taken care of inside the WinResource class, not in the nested class. The UnmanagedResourceWrapper works only as a wrapper for the handle and shouldn't contain other fields or methods, besides those shown in the above listing. The code in the WinResource class must coordinate all the resources being used, both managed and unmanaged ones, and must release all of them in its Dispose method. But if the client code omits to call the Dispose method, the destructor in the nested class will orderly release the unmanaged resource during the next garbage collection.

Let's see all the advantages of this simplified approach.

• The requirement that you shouldn't access reference fields from inside the Finalize method is automatically satisfied, because the only field of the UnmanagedResourceWrapper type is a handle (a value type).
• If the client code omits to invoke the WinResource.Dispose method before the WinResource object goes out of scope, the WinResource object is removed from the heap anyway at the first GC; only the few bytes used by the UnmanagedResourceWrapper object survive in the heap and will be promoted to generation 1 or 2. Therefore this technique is more efficient than writing a single finalizable object that allocates both managed and unmanaged resource.
• The UnmanagedResourceWrapper class is private and you can't inherit from it, therefore you can mark it as sealed. This means that you never have to worry about the Dispose/Finalize pattern in derived classes - a topic on which tons of digital ink has been spilled. It is possible to inherit from WinResource as you'd do with disposable class, therefore there are no limitations in this respect. (It's exactly like when you inherit from other disposable classes such as FileStream.)
• The UnmanagedResourceWrapper is private and nested in another type and it isn't possible to achieve a refernence to one of its instances; therefore, a client can't "resurrect" a UnmanagedResourceWrapper object during the finalization step, a technique that is rarely useful and often dangerous. (Even though I show in my Programming Visual Basic .NET book how you can use it to implement an object pool.)
• The UnmanagedResourceWrapper constructor performs a single "atomic" action; if this action fails, the value of the handle is still qual to InvalidHandle, therefore the code in the Finalize method can detect this special value and do nothing in that case. There are only two cases: either the unmanaged resource has been correctly allocated or an exception prevented it from being created, and you don't have to worry about an object that has been built only partially because of an exception in its constructor.
• Many other recommendations related to the Dispose/Finalize pattern become void, such as the one that dictates that you should neither write finalizers inside structures nor calling virtual methods from inside the finalizer. In fact, the UnmanagedResourceWrapper class is sealed and has no virtual methods. Nor do you have to worry about versioning issues.
• Another advantage: the UnmanagedResourceWrapper class is so simple and generic that you can ofter reuse it as-is (or with minor edits) inside other classes, by means of a plain copy-and-paste action. Being a nested class, you don't even need to change its name to avoid name collisions.

I am sure that in some cases this simplified pattern can't be used, though it always worked well in my applications. I believe that it's quite odd that this simplified approach is rarely mentioned in articles and books on this topic.

---

Technical matters aside, I think that another kind of consideration about the Dispose/Finalize pattern is in order.

In my opinion, it is essential to put a lot of emphasis on the fact that the Dispose/Finalize pattern should be used only when your type invokes unmanaged code that allocates unmanaged resources (including unmanaged memory) and returns an handle that you must use eventually to release the resource. If the unmanaged resource is already wrapped by a .NET object (e.g. a FileStream or a SqlConnection) or a COM object, the .NET class that uses the resource must implement IDisposable, not the finalizer. And you must implement the Finalize method only if your code assigns the handle to a class-level field. If the handle is assigned to a local variable and the unmanaged resource is released before exiting the method - possibly in the Finally section of a Try block - you don't even have to implement the IDisposable interface. One of the few exceptions to this rule is when your managed code allocates unmanaged memory directly, by means of the System.Runtime.InteropServices.Marshal type.

I talked to many developers who believe that, in doubt, they should always implement the Finalize method, just in case. This is a common mistake. Defining a finalizable class without a real reason to do so can hurt performance, because the CLR takes slightly longer to allocate finalizable objects, because it has to register them in the f-reachable queue. And in the worst case - that is if the caller omits to call to the Dispose method - a finalizable object can have even more impact on performance, because it will be promoted to a higher generation without any real reason for such an overhead.

To recap: when do you really need to implement the Finalize method? Thinking of all the commercial apps I worked on in these years, I'd say that I used this pattern no more than 4 or 5 times. For sure, I used it more frequently in books and articles than in the real world.

I work with Microsoft Press since 1998 and I wrote as many as 5 books for them (plus 3 more books I am working on right now). Every three months I get a check with my royalties from my US books and the translation rights for versions published elsewhere in the world, but without specifying which languages the books have been translated into.

For some reason I always forgot to ask for a list of the languages my books had been translated into, until a couple of months ago, when by acquisition editor made a search and returned this the following list. Every now and then, readers ask whether the book has been translated to their language, therefore I decided to post the information here.

Programming Microsoft Visual Basic 6 : English, Italian, Japanese, Korean, Spanish, Chinese (simplified, China), Chinese (traditional, Taiwan) + local English-language version in India.

Programming Microsoft Visual Basic .NET: English, Italian, French, Arabic, Japanese, Korean, Spanish, Chinese (simplified), Chinese (traditional) + local English-language versions in China and India.

Applied Microsoft .NET Framework Programming in Microsoft Visual Basic .NET (with Jeffrey Richter): English, Italian, Korean, Chinese (simplified), Chinese (traditional) + local English-language in China.

Programming Microsoft Visual Basic .NET Version 2003: English, Italian.

Practical Guidelines and Best Practices: English, Italiano, Russian + local English-language in China.

I can't help admitting that being translated into as many as ten languages is truly thrilling.

I am back from the Windows Professional Conference (Milan, Italy), for which I also server as the chairman for two of the four tracks. The conference touched virtually all the new features of Visual Studio and SQL Server 2005, plus tons of other topics. But that's another story.

When preparing the material for the conference I had to pack all my code samples in a zip file. Even after zipping them, I came up with a 7-8M file, which is a bit too much. So I was about to manually delete all the files that could be recreated by recompiling the projects. It's the same old story, that repeat itself with all conferences, books, articles for magazines and blog posts.

Instead of using the manual approach, this time I decided to write a tiny utility that does the work for me. It took (literally) two minutes to write a console utility that takes the path as an argument and recurses over that directory tree to remove all the folders named "bin" and "obj". If a delete operation fails, a message error is displayed. (This happens when an executable is running and is therefore locked by the operating system.) The code is especially concise thanks to an overload of the Directory.GetDirectories method (added in .NET 2.0) that returns all the directory in a tree.

Imports System.IO

Module Module1
   Sub Main(ByVal args() As String)
      ' Use current directory if no argument has been specified
      Dim rootDir As String = Directory.GetCurrentDirectory()
      If args.Length > 0 Then rootDir = args(0)
      ' Read all the folder names in the specified directory tree
      Dim dirNames() As String = Directory.GetDirectories(rootDir, "*.*", SearchOption.AllDirectories)
      Dim errors As Integer = 0

      ' Delete all the BIN and OBJ subdirectories
      For Each dir As String In dirNames
         Dim dirName As String = Path.GetFileName(dir).ToLower()
            If dirName = "bin" OrElse dirName = "obj" Then
               Try
                  Console.Write("Deleting {0} ...", dir)
                  Directory.Delete(dir, True)
                  Console.WriteLine("DONE")
               Catch ex As Exception
                  Console.WriteLine()
                  Console.WriteLine(" ERROR: {0}", ex.Message)
                  errors += 1
               End Try
            End If
         Next

         Console.WriteLine()
         If errors = 0 Then
            Console.WriteLine("All directories were removed successfully")
         Else
            Console.WriteLine("{0} directories couldn't be removed")
         End If
     End Sub
End Module

In addition to using this tool from the command line, you can add it to the Tools menu, so that you can quickly delete all the files produced by compiling the current solution, by using this command:

               DELETEBINPATH $(SolutionDir)

where of course DeleteBinPath is the name you used when compiling the utility.

UPDATE: I have posted a new version of this utility in a more recent post.

Let's consider the following code, which represents a typical situation: you are inside a nested loop and you want to exit both loops when a condition is true:

For i As Integer = 1 To 10
   Dim exiting As Boolean = False
   For j As Integer = 1 To 20
      ' If the Evaluate function returns zero you want to exit both loops
      If Evaluate(i, j) = 0 Then
         exiting = True
         Exit For
      End If
      ' Do something here
   Next
   If exiting Then Exit For
Next

It isn't important to understand what the Evaluate function does, just consider that when this function returns zero you must exit both loops. The above code isn't optimized, because it repeatedly tests the exiting variable. You might optimize the loop by using a Goto statement that points to a label following the second Next keyword, but educated programmers don't use Gotos, right? So, the question is simple: how can you simplify this code and optimize it at the same time by dropping the exiting variable?

The solution is simple, and is based on the fact that Visual Basic supports as many as three different kinds of loops: For, Do, and While. Each kind of loop supports a corresponding Exit keyword (Exit For, Exit Do, and Exit While), thus you can rewrite the code as follows:

Dim i As Integer = 1
Do While i <= 10
   For j As Integer = 1 To 20
      If Evaluate(i, j) = 0 Then Exit Do
      ' Do something here
   Next
   i += 1
Loop

You can use the same technique when you have up to three nested loops.

Incidentally, you can't adopt this technique in C#, because its break statement doesn't have the same "semantics power" of the Exit keyword in VB.

I am reviewing the chapter devoted to the My Namespace and I am adding a few details that I overlooked in the first draft, such as the creation of custom setting providers (to save settings on a medium other than the configuration file, e.g. a database) and the ability to bind a control's property to a user sertting. Custom setting providers are relatively complex and are of interest for a relatively small number of users, whereas setting binding is a simpler topic that will surely draw the attention of any developer working with Windows Forms applications.

I found many articles and posts on the My.Settings object (VB) and Settings object (C#), but most of them omit to emphasize the ability to bind a user setting to a form property, such as the Size and Location properties. This feature enables you - among the many things - to restore the size and position of a form from a previous session. The .NET infrastructure automatically assigns these properties when the form is loaded and save them when the form is resized or moved.

Figure 1. Visual Studio 2005 enables you to define user-level and application-level settings

Figure 2. How to bind a property to a user-level setting.

The great thing of this technique is that you don't need to write a single line of code. In fact, you just need to define one or more settings in the Settings page of the My Project designer (Visual Basic) or Properties designer (C#), for example the MainFormLocation and MainFormSize settings (see Figure 1). It is crucial that these settings are defined as user settings, because application-level settings are read-only. Next, you can select the form, switch to the Properties window, open the (Application Settings) section, click on the arrow near the ClientSize and Location properties, and select the user setting you want to bind the property to. If you haven't created the user setting yet, you can do it now by clicking on the New element. (See Figure 2.) As I already noted, the noteworthy detail is that these settings are automatically updated when the end user moves or resizes the form. You can bind other properties, for example Text, BackColor, etc. If you perform this action for all the forms in the application, you can implement a simple yet powerful persistance mechanism for all user's preferences, again without writing code! Obviously, you can extend this mechanism to properties of individual controls. Not all properties can notify to the world that they have been modified, though. More precisely, the control that exposes the property must implement the IBindableComponent interface and must expose an event named XxxxChanged for each property, or it must implement the INotifyPropertyChanged interface (new in .NET 2.0). Most Windows Forms controls, but not all of them, implement these interfaces. For example, the ToolStripItem control doesn't implement it. In this case, the property is assigned correctly when the form loads, but you must update the corresponding user setting via code.

Visual Studio 2005 comes with dozens of ready-to-use code snippets. You might argue on the usefulness of some of them, but for sure many of them are really well-conceived. For example, the prop expansion that creates public C# properties is a real time saver.

The Code Snippet Manager dialog box (in the Tools menu) enables you to inspect all the installed snippets, one by one, but doesn't offer the option to export a list of all the snippets, therefore you have to browse them one by one to take notice of their name, purpose, and keyboard shortcut. While I was working on chapter 4 of Programming Microsoft Visual Basic 5, I wrote this little throw-away program which decodes the snippet index and list them on a console window. Of course you can redirect the output to a file to have a document that you can use as a reference.

The program takes a parameter equal to the path of the SnippetIndex.xml (VB) or SnippetsIndex.xml (C#) file that contains the snippet index. (Oddly, this file has a slightly different name in the two languages.) If you run it without passing any argument, it uses the path of the VB snippet index in a default Visual Studio installation. A comment in the listing explains how you can use the default index for C# instead.

The output of this code is quite terse - just snippet names and shortcuts, grouped in categories - but you can easily modify the source code to extract and display more attributes.

Imports System.IO
Imports System.Xml
Imports System.Text.RegularExpressions

Module Module1
   Dim snippetsPath As String
   Dim catNames As New Dictionary(Of String, String)

   Sub Main(ByVal args() As String)
      ' If no argument has been provided, use default path for snippets.
      If args.Length = 0 Then
         args = New String() {"C:\Program Files\Microsoft Visual Studio 8\Vb\Snippets\1033\SnippetIndex.xml"}
         ' Uncomment next line to list C# snippets
         ' args = New String() {"C:\Program Files\Microsoft Visual Studio 8\VC#\Snippets\1033\SnippetsIndex.xml"}
      End If

      Dim snippetsFile As String = args(0)
      snippetsPath = Path.GetDirectoryName(snippetsFile)
      ' Load the snippet index file.
      Dim xmlIndex As New XmlDocument()
      xmlIndex.Load(snippetsFile)
      ' We need two passes, because dirs and subdirs use a different XML element.
      ParseSnippetIndex(xmlIndex, "//SnippetDir")
      ParseSnippetIndex(xmlIndex, "//SnippetSubDir")
      ' Iterate over all the directories in the main snippet directory.
      For Each dir As String In Directory.GetDirectories(snippetsPath)
         ParseSnippetFolder(dir, "")
      Next
   End Sub

   Sub ParseSnippetIndex(ByVal xmlIndex As XmlDocument, ByVal searchKey As String)
      ' Create the correspondence between relative paths and localized categories
      For Each xmlEl As XmlElement In xmlIndex.SelectNodes(searchKey)
         Dim elPath As XmlElement = DirectCast(xmlEl.SelectSingleNode("DirPath"), XmlElement)
         Dim elName As XmlElement = DirectCast(xmlEl.SelectSingleNode("LocalizedName"), XmlElement)
         catNames.Add(elPath.InnerText, elName.InnerText)
      Next
   End Sub

   Sub ParseSnippetFolder(ByVal dir As String, ByVal parentCategory As String)
      ' Retrieve the relative name of this subdirectory.
      Dim relPath As String = dir.Substring(snippetsPath.Length)
      ' The default name for this category
      Dim categoryName As String = parentCategory & Path.GetFileNameWithoutExtension(dir)
      ' Search this relative path in the snippet index.
      Dim searchPath As String = "%InstallRoot%\Vb\Snippets\%LCID%" + relPath + "\"
      If catNames.ContainsKey(searchPath) Then
         ' If found, use the localized category as appears in the index file
         categoryName = parentCategory & catNames(searchPath)
      End If
      Console.WriteLine(categoryName.ToUpper())
      ' Parse individual snippets in this directory.
      For Each file As String In Directory.GetFiles(dir, "*.snippet")
         ParseSnippetFile(file)
      Next
      ' Parse all sub-categories
      For Each subdir As String In Directory.GetDirectories(dir)
         ParseSnippetFolder(subdir, categoryName & " / ")
      Next
   End Sub

   Dim reTitle As New Regex("<Title>(.+?)</Title>")
   Dim reShortcut As New Regex("<Shortcut>(.+?)</Shortcut>")

   Sub ParseSnippetFile(ByVal snippetFile As String)
      Dim text As String = File.ReadAllText(snippetFile)
      ' We use regexes to extract information for individual snippet files.
      Dim maTitle As Match = reTitle.Match(text)
      Dim maShortcut As Match = reShortcut.Match(text)
      Dim title As String = maTitle.Groups(1).Value
      Dim shortcut As String = maShortcut.Groups(1).Value
      Console.WriteLine(" {0} [{1}]", title, shortcut)
   End Sub
End Module

I find it quite ironical that many developers spend hours to debate which language is the most efficient or productive, and yet forget to learn how to use the tool with which they spend most of their time: the Visual Studio IDE.

The best way to increase productivity with Visual Studio is to write macros that automate repetitive tasks. There are many commercial and freeware add-ins on the market, but I rarely find one that does exactly what I need. In cases like this I just write a macro, either from scratch or starting with a recorded macro that captures the actions that I want to repeat.

For example, I found that I typically prototype my classes with Public fields, but then I convert them to properties when I convert the prototype to the "real" code. The conversion process takes me a lot of time. To see what I mean, I typically start with a simple variable such as

' The name of the element
Public Name As String = "Francesco"

and I convert it into something like this:

' The name of the element
Private m_Name As String = "Francesco"

Public Property Name() As String
   Get
      Return m_Name 
   End Get
   Set(ByVal Value As String)
      m_Name = Value
   End Set
End Property

At last, some months ago I decided to write a macro that automates this conversion. It took me about 30 minutes, but in these months it saved me hours. Here it is:

Imports EnvDTE
Imports System.Text.RegularExpressions

Public Module CodeArchitectsMacros
   Dim repPattern As String
   Dim repPatternReadOnly As String

   Sub ConvertVariables()
      ' Determine current language by looking at the extension of the current document.
      Dim doc As Document = DTE.ActiveDocument
      If doc Is Nothing Then Exit Sub
      Dim docName As String = doc.Name.ToLower()

      ' Read all the text lines touched by the selection.
      Dim sel As TextSelection = CType(DTE.ActiveDocument.Selection, TextSelection)
      Dim ed1 As EditPoint = sel.AnchorPoint.CreateEditPoint()
      ed1.EndOfLine() : ed1.StartOfLine() : ed1.StartOfLine()
      Dim ed2 As EditPoint = sel.BottomPoint.CreateEditPoint()
      ed2.EndOfLine()
      Dim text As String = ed1.GetText(ed2)

      ' The find and replacement pattern depend on the current language.
      Dim findPattern As String
      If docName.EndsWith(".vb") Then
         findPattern = "(?<indent>[\t ]+)Public\s+(?<static>Shared\s+)?(?<readonly>ReadOnly\s+)?" _
            & "(?<name>\w+)\s+As\s+(?<type>\S+)(?<init>.*?)\n"
         ' {0}=property name, {1}=property type, {2}=static keyword, {3} initvalue,
         ' {4}=CR-LF, {5}=Tab, {6}=indent
         repPattern = "{6}Private {2}m_{0} As {1}{3}{4}" _
            & "{6}Public {2}Property {0}() As {1}{4}" _
            & "{6}{5}Get{4}" _
            & "{6}{5}{5}Return m_{0}{4}" _
            & "{6}{5}End Get{4}" _
            & "{6}{5}Set(ByVal Value As {1}){4}" _
            & "{6}{5}{5}m_{0} = Value{4}" _
            & "{6}{5}End Set{4}" _
            & "{6}End Property{4}{4}"
         repPatternReadOnly = "{6}Private {2}ReadOnly m_{0} As {1}{3}{4}" _
            & "{6}Public ReadOnly {2}Property {0}() As {1}{4}" _
            & "{6}{5}Get{4}" _
            & "{6}{5}{5}Return m_{0}{4}" _
            & "{6}{5}End Get{4}" _
            & "{6}End Property{4}{4}"
      ElseIf docName.EndsWith(".cs") Then
         ' Notice the (?.*;) element is needed to ensure that public fields are matched,
         ' but public properties aren't
         findPattern = "(?<indent>[\t ]+)public\s+(?<static>static\s+)?(?<readonly>readonly\s+)?" _
            "(?<type>\S+)\s+(?<name>\w+)(?=.*;)(?<init>.*?)\n"
         ' {0}=property name, {1}=property type, {2}=static keyword, {3} initvalue,
         ' {4}=CR-LF, {5}=Tab, {6}=indent
         repPattern = "{6}private {2}{1} m_{0}{3}{4}" _
            & "{6}public {2}{1} {0}{4}" _
            & "{6}{{{4}" _
            & "{6}{5}get {{ return m_{0}; }}{4}" _
            & "{6}{5}set {{ m_{0} = value; }}{4}" _
            & "{6}}}{4}{4}"
         repPatternReadOnly = "{6}private {2}readonly {1} m_{0}{3}{4}" _
            & "{6}public {2}{1} {0}{4}" _
            & "{6}{{{4}" _
            & "{6}{5}get {{ return m_{0}; }}{4}" _
            & "{6}}}{4}{4}"
      End If

     ' Replace the text. Add a trailing CR-LF but remove it later.
     Dim replaceText As String = Regex.Replace(text + ControlChars.CrLf, findPattern, _
        AddressOf ReplaceWithProperty)
     ed1.ReplaceText(ed2, replaceText.Substring(0, replaceText.Length - 2), 0)
   End Sub

   ' Private callback function for the Replace method
   Private Function ReplaceWithProperty(ByVal m As Match) As String
      Dim pattern As String = repPattern
      If m.Groups("readonly").Length > 0 Then pattern = repPatternReadOnly
      Return String.Format(pattern, m.Groups("name").Value, m.Groups("type").Value, _
         m.Groups("static").Value, m.Groups("init").Value, ControlChars.CrLf, _
         ControlChars.Tab, m.Groups("indent").Value)
   End Function

End Module

Thanks to regular expressions, and in spite of the low amount of code it contains, this macro works both in VB and C#, it enables you to convert multiple fields in one shot, it preserves the field's initial value and even its static/Shared and Readonly attributes, and it also preserves any statement between variable declarations. In practice, therefore, you can just select the source code of an entire class and convert all its public fields into properties, with just a mouse click!

For each property, the macro creates a variable named m_PropertyName; obviously you can use your favorite naming convention by editing the statement that assigns regPattern. C# developers can edit the code to generate multi-lined get/set blocks. (I prefer to have more compact blocks.)

The Array class has been expanded with many generic methods. For example, consider the following code:

int[] intArray = new int[] { 12, 34, 56, 78, 90 };
// convert each element to hex
string[] strArray = new string[intArray.Length];
for (int i = 0; i < intArray.Length; i++)
{
   strArray[i] = intArray[i].ToString("X");
}
// display the result in the Console window
foreach (string s in strArray)
{
   Console.WriteLine(s);
}

Using the Array.ConvertAll method and an anonymous method you can simplify the conversion loop as follows:

string[] strArray = Array.ConvertAll<int, string>(intArray, delegate(int n)
                        { return n.ToString("X"); });

Surprisingly, however, you can simplify this code even further and even render it with VB 2005 (which doesn't support anonymous methods). The trick is to find a static method in the .NET Framework that takes a number and returns the argument's hex value. Strictly speaking, the .NET Framework doesn't expose a type with such a method, but you can use the Hex method of the Microsoft.VisualBasic.Conversion type:

// this code requires a reference to the Microsoft.VisualBasic.dll
string[] strArray = Array.ConvertAll<int, string>(intArray, Microsoft.VisualBasic.Conversion.Hex);

' This the VB version
Dim strArray As String() = Array.ConvertAll(Of Integer, String)(intArray, AddressOf Hex)

The Visual Basic library exposes a few other methods that you can use in this fashion, for example UCase, LCase, Trim, LTrim, RTrim, Int, Val, Asc, Chr, Len. You can find other useful methods everywhere in the .NET Framework, for example the Convert class.

Likewise, you can replace the loop that displays the results to the console window with a simpler Array.ForEach method

// C#
Array.ForEach<string>(strArray, Console.WriteLine);

' VB
Array.ForEach(Of String)(strArray, AddressOf Console.WriteLine)

Here's a non-orthodox but quite effective technique I sometimes use to detect and avoid recursive calls to a method. You typically detect recursive calls by defining a boolean class-level field and testing it on entry to a method. This technique is often used in event handlers, for example in TextChanged handlers that modify the Text property of a control and that would therefore trigger an endless recursion:

Dim insideTextChanged As Boolean

Private Sub TextBox1_TextChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles TextBox1.TextChanged
   ' Exit if this is a recursive call.
   If insideTextChanged Then Exit Sub
   ' Forbid recursive calls from now on.
   insideTextChanged = True
   ' ...
   TextBox1.Text = TextBox1.Text & " "
   ' Permit recursive calls.
   insideTextChanged = False
End Sub

This approach works well, but it requires a lot of code and forces you to define a distinct boolean field for each event handler. If you have many handlers, it quickly becomes a nuisance. In addition, if there is any chance that the method throws an exception, you must wrap all the code in a try block,so that you can reset the insideTextChanged to false in the finally section. Wouldn't it great if you could use a method that allows you to test if you are inside a recursive call? I am thinking of something like this:

Private Sub TextBox1_TextChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles TextBox1.TextChanged
   ' Exit if this is a recursive call.
   If IsRecursive() Then Exit Sub
   ' ...
   TextBox1.Text = TextBox1.Text & " "
End Sub

Here's how you can implement the IsRecursive method:

<System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)> _
Public Shared Function IsRecursive() As Boolean
   Dim st As New StackTrace
   ' Check whether any method in the call stack is the same as the immediate caller.
   For n As Integer = 2 To st.FrameCount - 1
      If st.GetFrame(1).GetMethod() Is st.GetFrame(n).GetMethod() Then Return True
   Next
   Return False
End Function

Here's the C# version:

[System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)]
public static bool IsRecursive() 
{
   StackTrace st = new StackTrace();
   // Check whether any method in the call stack is the same as the immediate caller.
   for ( int n= 2; n < st.FrameCount; n++ )
   {
      if ( st.GetFrame(1).GetMethod() == st.GetFrame(n).GetMethod() ) 
         return true;
   }
   return false;
}

The IsRecursive method compares the immediate caller - that is, st.GetFrame(1).GetMethod() - with all the other methods on the call stack and returns True if it finds a match. It is essential that the IsRecursive method is decorated with the MethodImpl attribute, to ensure that the JIT compiler inlines it in its caller's body. In .NET 1.1 this should never happen, because the JIT compiler never inlines methods that contain loops, but I haven't checked under .NET 2.0 and obviously I can't make promises about future versions, therefore this attribute is your best defence.

C# 2.0 has Surround With command that enables you to wrap the selected code inside a if, for, foreach, while, #if (and a few mode) blocks. Some of the options are virtually useless - for example, I'd never wrap a piece of code in a class, interface, or enum block - but all in all it's a very handy command. Actually, it is so convenient that I decided to create a set of Visual Studio macros that add the same functionality to Visual Basic (both 2003 and 2005 editions) and C# 2003.

To install and use the macros listed below, add the following module to the Macro IDE, go back to Visual Studio, select a piece of code, open the WrappingMacros element in the Macro Explorer window, and double-click the macro you want to apply. In some cases, after applying the macro you'll also need to edit the generated code, for example to insert a condition in the If statement or the name of the #region you've created. Also, if you are working with C# you should manually reformat the selected code (by typing Ctrl+K, Ctrl+F), because for some reason the Edit.FormatSelection command works only in Visual Basic.

Even better, you should associate the macros you like most with a keyboard shortcut, so that you can apply the macro without opening the Macro Explorer window. If you need to list which shortcuts are available, have a look at yesterday's post.

Imports System
Imports EnvDTE

Public Module WrappinglMacros

   ' --------------------------------------------------------------------
   ' Wrap the selected code inside IF, TRY, etc.
   ' --------------------------------------------------------------------

   Public Sub WrapIf()
      WrapCode("WrapIf", "If True Then\n$sel$End If\n", "if ( true )\n{\n\t$sel$}\n")
   End Sub

   Public Sub WrapIfElse()
      WrapCode("WrapIfElse", "If True Then\n$sel$Else\n\nEnd If\n", "if ( true )\n{\n\t$sel$}\nelse\n{\n}\n")
   End Sub

   Public Sub WrapTryCatch()
      WrapCode("WrapTryCatch", "Try\n$sel$Catch ex As Exception\n\nEnd Try", _
         "try\n{\n$sel$}\ncatch (Exception ex)\n{\n}\n")
   End Sub

   Public Sub WrapTryFinally()
      WrapCode("WrapTryFinally", "Try\n$sel$Finally\n\nEnd Try", "try\n{\n$sel$}\nfinally\n{\n}\n")
   End Sub

   Public Sub WrapTryCatchFinally()
      WrapCode("WrapTryCatchFinally", "Try\n$sel$Catch ex As Exception\n\nFinally\n\nEnd Try", _
         "try\n{\n$sel$}\ncatch (Exception ex)\n{\n}\nfinally\n{\n}\n")
   End Sub

   Public Sub WrapRegion()
      WrapCode("WrapRegion", "#Region ""RegionName""\n\n$sel$\n#End Region", _
         "#region RegionaName\n\n$sel$\n#endregion")
   End Sub

   Public Sub WrapSharpIf()
      WrapCode("WrapSharpIf", "#IF True Then\n\n$sel$\n#End If", "#if true\n\n$sel$\n#endif")
   End Sub

   Public Sub WrapFor()
      WrapCode("WrapFor", "For index As Integer = startIndex To endIndex\n$sel$Next", _
         "for (int index = startIndex; i <= endIndex; index++)\n{\n$sel$}\n")
   End Sub

   Public Sub WrapForEach()
      WrapCode("WrapForEach", "For Each obj As Object In collection\n$sel$Next", _
         "foreach (object obj in collection)\n{\n$sel$}\n")
   End Sub

   Public Sub WrapWhile()
      WrapCode("WrapWhile", "Do While True\n$sel$Loop", "while (true)\n{\n$sel$}\n")
   End Sub

   Public Sub WrapDoWhile()
      WrapCode("WrapDoWhile", "Do\n$sel$Loop While True", "do\n{\n$sel$} while ( true );\n")
   End Sub

   Public Sub WrapNamespace()
      WrapCode("WrapNamespace", "Namespace NamespaceName\n$sel$End Namespace", _
         "namespace NamespaceName\n{\n$sel$} // end of namespace")
   End Sub

   Public Sub WrapSelect()
      WrapCode("WrapSelect", "Select Case expression\nCase 0\n$sel$Case 1\nCase Else\nEnd Select\n", _
         "switch ( expression )\n{\n\tcase 0:\n\t\tbreak;\n\tcase 1:\n\t\tbreak;\n\tdefault:\n\t\tbreak;\n}\n")
   End Sub

   Public Sub WrapSyncLock()
      WrapCode("WrapIf", "SyncLock lockObject\n$sel$End SyncLock\n", "lock ( lockObject )\n{\n\t$sel$}\n")
   End Sub

   ' Helper method that replaces the selection with the specified templated text.
   ' The template can include $sel$ (the selected code) and escape sequences such as \r\n, \t
   Private Sub WrapCode(ByVal cmdName As String, ByVal vbTemplate As String, ByVal csTemplate As String)
      ' Determine the current language by looking at the extension of the current document.
      Dim doc As Document = DTE.ActiveDocument
      If doc Is Nothing Then Exit Sub
      Dim docName As String = doc.Name.ToLower()
      Dim sel As TextSelection = DirectCast(DTE.ActiveDocument.Selection, TextSelection)
      If sel Is Nothing Then Exit Sub

      ' Open an undo context.
      DTE.UndoContext.Open(cmdName)
      ' Retrieve the selected text, append a newline if necessary.
      Dim selText As String = sel.Text
      If Not selText.EndsWith(ControlChars.NewLine) Then selText &= ControlChars.NewLine

      ' Wrap the selected text, using either the VB or the C# command
      Dim template As String
      If docName.EndsWith(".vb") Then
         template = vbTemplate
      ElseIf docName.EndsWith(".cs") Then
         template = csTemplate
      End If

      ' Replace CR-LF, tabs, and the selected text
      Dim newText As String = Regex.Unescape(template).Replace("$sel$", selText)
      ' Reselect the text just added and format it. (Doesn't work in C#.)
      Dim ep As EditPoint = sel.TopPoint.CreateEditPoint()
      sel.Text = newText
      sel.MoveToPoint(ep, True)
      DTE.ExecuteCommand("Edit.FormatSelection")
      ' Close the undo context.
      DTE.UndoContext.Close()
   End Sub

End Module

When you create a macro and want to associate it with a shortcut key you face the problem of determining which shortcuts are available. At times this can become a time-consuming job, because Visual Studio has taken so many shortcuts for itself. More in general, how do you get the list of all the Visual Studio commands and their shortcuts, as defined in a given keyboard configuration?

The most obvious answer is "read the documentation, dude!", however the docs can't list the shortcuts that have been modified or added after installing Visual Studio. Microsoft provides the Keybindings Table Add-in, an add-in written in C++ that lists all key bindings (that is, the shortcuts associated with each command). But why should you install an add-in if you can achieve the same result with a macro that contains just a few lines of code? Here's a macro that creates a text file in the C:\ folder, with all the information you need:

Public Sub ShowKeyboardBindings()
   Dim sw As New System.IO.StreamWriter("c:\keybindings.txt")
   For Each cmd As Command In DTE.Commands
      For Each o As Object In cmd.Bindings
         sw.WriteLine(cmd.Name & " - " & o.ToString())
      Next
   Next
   sw.Close()
End Sub

The advantage of using a macro instead of the shrik-wrapped add-in is that you can modify its source code to display information in any format you like. For example, you might sort the result by the shortcut, so that you can immediately see which shortcuts are used and which are available. Or you can list only the commands that are available inside a given window, such as the code editor or the form designer.

If you aren't familiar with macros, here's how to proceed. Type Alt+F11 to bring up the Macro IDE, open a module under MyMacros (e.g. Module1) by clicking in the Project Explorer, then paste the previous code and type Ctrl+S to save. Close the Macro IDE and go back to Visual Studio, type Alt+F8 to display the Macro Explorer window, expand the MyMacros-Module1 node and double-click on ShowKeyboardBinding to run the macro. Done!

Have a look at this simple Visual Basic code snippet:

' The version that does NOT cache the value type in a reference variable.
Dim start As Date = Now
For i As Integer = 1 To 1000
   For j = 1 As Integer To 100000
      GetObject(i, j)
   Next
Next
Console.WriteLine("Version 1: " & Now.Subtract(start).ToString)
GC.Collect() : GC.WaitForPendingFinalizers()

' The version that caches the value type in a reference variable.
start = Now
For i = 1 As Integer To 1000
   ' Cache the value type in an Object variable.
   Dim o As Object = i
   For j As Integer = 1  To 100000
      GetObject(o, j)
   Next
Next
Console.WriteLine("Version 2: " & Now.Subtract(start).ToString)

GetObject is a very simple routine, that takes two objects and therefore causes a box operation if they are value types:

Private Function GetObject(ByVal o As Object, ByVal o2 As Object) As Object
   Return o
End Function

As you can read in comments, the second portion caches the boxed version of the i variable in an Object variable, because this value doesn't change inside the innermost loop. You'd expect that this second version would run faster, even if by a little, and in fact this is what happens with Visual Basic .NET 2003. However, if you try this code with VB 2005 you'll be surprised to see that - as counterintuitive as it sounds - the version that caches the boxed value is 30-40% slower!

You need ILDASM to understand what happens behind the scenes. Visual Basic calls the GetObjectValue static method of the RuntimeHelpers type (in the System.Runtime.CompilerServices namespace) before passing an object variable to an object argument, and this extra call explains the overhead just observed. The weird thing is that this extra call is generated by the VB2003 compiler as well, however it doesn't nullify our manual optimization based on the cached variable. I am doing the benchmark with the RTM version, therefore this overhead is real (in other words, it isn't caused by pieces of the CLR compiled in debug mode), therefore I can only conclude that the 2.0 version of the GetObjectValue method is less efficient than the 1.1 version.

This is what the GetObjectValue method does. (Thanks to Adrian Florea, who found this note in Rotor's source code.)

GetObjectValue is intended to allow value classes to be manipulated as Object but have aliasing behavior of a value class. The intent is that you would use this function just before an assignment to a variable of type Object. If the value being assigned is a mutable value class, then a shallow copy is returned (because value classes have copy semantics), but otherwise the object itself is returned.

Note: VB calls this method when they're about to assign to an Object or pass it as a parameter. The goal is to make sure that boxed value types work identical to unboxed value types - ie, they get cloned when you pass them around, and are always passed by value. Of course, reference types are not cloned."

Every now and then I discover a Visual Studio shortcut that doesn't correspond to any menu command. Not all these under-documented shortcuts are truly useful, but a few of them can help you accellerate common editing operations and save a fraction of a second. Adding one fraction of a second today and tomorrow, at the end of your programming career you will save two or three entire days. Maybe in those days it will be raining (quoting Woody Allen), but that's a different story Here are some of my discoveries:

Ctrl+L cuts the current line into the Clipboard
CStrl+Shift+L deletes the current line without copying it in the Clipboard.
Ctrl+C, if no text is currently selected, it copies the current line in the Clipboard.
Ctrl+Enter creates an empty line above the current line.
Ctrl+Shift+Enter creates an empty line below the current line.

Ctrl+Shift+T swaps the current word with the word on its right (word transpose).
Ctrl+Alt+T swaps the current line with the next line (line transpose) thus you can easily move a line elsewhere in the listing

Ctrl+F3 finds the next occurrence of the searched text.
Ctrl+Shift+F3 finds the previous occurrence of the searched text.

Ctrl+F10 invokes the Run to Cursor command in debug mode.
Ctrl+Shift+F10 invokes the Set Next Statement command in debug mode.
Ctrl+* (on the numeric keypad) invokes the Show Next Statement command.

Ctrl+PgUp e Ctrl+PgDn move to the previous and next toolwindow among those that are usually hosted near the right border of the IDE, enabling you to cycle among the Solution Explorer, Properties window, Class View window, etc.
Alt+Shift+F6 e Alt+F6 move to the previous and next window among those hosted in the bottommost panel, enabling you to cycle among the Immediate, Command, Task List, and Threads window.
Shift+Esc closes a toolwindow.

All these shortcuts are active if youselect the Visual Studio's default keyboard configuration. If you enabled a different keyboard configuration (e.g. Visual Basic), some of these shortcuts won't work. You can modify the keyboard configuration in the Keyboard page of the Tools-Options dialog box.

I am reviewing the chapter on execution flow in Visual Basic 2005, where I cover recursion - among the many things. In most programming books I've read, recusion is explained with the "classic" factorial example (which can be implemented more efficiently with a simple For loop) or as a means to visit tree structures. It looks like recursion isn't useful in the "average" business application, which of course isn't the case. As most programming techniques, it's mostly a matter of knowing when and where to exploit it.

Here's an example of recursion that you might find quite useful: a method that converts an integer into its textual representation, e.g. 1234 into "One Thousand Two Hundreds Thirty Four", taken from my forthcoming Microsoft Press book Programming Microsoft Visual Basic 2005.

Public Shared Function NumberToText(ByVal n As Integer) As String
   Select Case n
      Case Is < 0
         Return "Minus " & NumberToText(-n)
      Case 0
         Return ""
      Case 1 To 19
         Dim arr() As String = {"One", "Two", "Three", "Four", "Five", "Six", _
            "Seven", "Eight", "Nine", "Ten", "Eleven", "Twelve", "Thirteen", _
            "Fourteen", "Fifteen", "Sixteen", "Seventeen", "Eighteen", "Nineteen"}
         Return arr(n - 1) & " "
      Case 20 To 99
         Dim arr() As String = {"Twenty", "Thirty", "Forty", "Fifty", "Sixty", _
            "Seventy", "Eighty", "Ninety"}
         Return arr(n \ 10 - 2) & " " & NumberToText(n Mod 10)
      Case 100 To 199
         Return "One Hundred " & NumberToText(n Mod 100)
      Case 200 To 999
         Return NumberToText(n \ 100) & "Hundreds " & NumberToText(n Mod 100)
      Case 1000 To 1999
         Return "One Thousand " & NumberToText(n Mod 1000)
      Case 2000 To 999999
         Return NumberToText(n \ 1000) & "Thousands " & NumberToText(n Mod 1000)
      Case 1000000 To 1999999
         Return "One Million " & NumberToText(n Mod 1000000)
      Case 1000000 To 999999999
         Return NumberToText(n \ 1000000) & "Millions " & NumberToText(n Mod 1000000)
      Case 1000000000 To 1999999999
         Return "One Billion " & NumberToText(n Mod 1000000000)
      Case Else
         Return NumberToText(n \ 1000000000) & "Billions " _
            & NumberToText(n Mod 1000000000)
   End Select
End Function

Here's the version for curly braces' lovers. C# switch keyword doesn't support ranges, thus I had to change the code to use a series of elseif blocks:

public static string NumberToText( int n)
{
   if ( n < 0 )
      return "Minus " + NumberToText(-n);
   else if ( n == 0 )
      return "";
   else if ( n <= 19 )
      return new string[] {"One", "Two", "Three", "Four", "Five", "Six", "Seven", "Eight", 
         "Nine", "Ten", "Eleven", "Twelve", "Thirteen", "Fourteen", "Fifteen", "Sixteen", 
         "Seventeen", "Eighteen", "Nineteen"}[n-1] + " ";
   else if ( n <= 99 )
      return new string[] {"Twenty", "Thirty", "Forty", "Fifty", "Sixty", "Seventy", 
         "Eighty", "Ninety"}[n / 10 - 2] + " " + NumberToText(n % 10);
   else if ( n <= 199 )
      return "One Hundred " + NumberToText(n % 100);
   else if ( n <= 999 )
      return NumberToText(n / 100) + "Hundreds " + NumberToText(n % 100);
   else if ( n <= 1999 )
      return "One Thousand " + NumberToText(n % 1000);
   else if ( n <= 999999 )
      return NumberToText(n / 1000) + "Thousands " + NumberToText(n % 1000);
   else if ( n <= 1999999 )
      return "One Million " + NumberToText(n % 1000000);
   else if ( n <= 999999999)
      return NumberToText(n / 1000000) + "Millions " + NumberToText(n % 1000000);
   else if ( n <= 1999999999 )
      return "One Billion " + NumberToText(n % 1000000000);
   else 
      return NumberToText(n / 1000000000) + "Billions " + NumberToText(n % 1000000000);
}

These methods are much simpler than any similar code I've found on the Internet, thanks to recursion. I really love OOP, generics, attributes, regular expressions, and other advanced language features, but I also like to reming that you can often write elegant, compact, and efficient code just leveraging the features that mainstream languages have offered for decades.

VB.NET and C# compilers manage string constants in a rather smart way: all strings with same value are stored in a common area known as string intern pool. The following code snippet shows this compiler feature in action:

' VB.NET
Dim s1 As String = "ABCDE"
Dim s2 As String = "ABC" & "DE"
' Prove that s1 and s2 point to the same element in the intern pool
Console.WriteLine(s1 Is s2) ' => True

// C#
string s1 = "ABCDE";
string s2 = "ABC" + "DE";
// Prove that s1 and s2 point to the same element in the intern pool
Console.WriteLine(String.ReferenceEquals(s1, s2)); // => True

This optimization technique doesn't really have any impact on the amount of memory used by most client applications, but it makes a difference if used inside types that are instantiated thousand times, as it often happens in server applications. The problem is, this optimization is applied only to string constants, not to strings built at runtime:

' VB.NET ...continuing previous example...
Dim s3 As String = "ABC"
s3 &= "DE"
' s1 and s3 contain the same value but point to a different string
Console.WriteLine(s1 = s3) ' => True
Console.WriteLine(s1 Is s3) ' => False

// C# ... continuing previous example...
string s3 = "ABC";
s3 += "DE";
Console.WriteLine(s1 == s3) // => True
Console.WriteLine(String.ReferenceEquals(s1, s3) // => False

Now, let's suppose you have a component in the data tier and this component contains the the connection string for the database. This connection string is read from somewhere - typically the configuration file - when it's time to open the connection, therefore the compiler can't store the string in the intern pool. If this component is instantiated N times, there will be N copies of the same string in memory, which clearly is a waste if the string is long and N is high. There are two ways to avoid this waste, depending on how the connection string can vary.

If the connection string is guaranteed to be the same for all the instances, then you can store it in a static variable (a Shared variable in VB), so that the string is shared among all the instances of the component. This is the simplest case and I assume you know how to implement it, so let's move to the more interesting situation.

If the connection string can vary - for example, if the data component can connect to two or more different databases or if the connection string can use different login information - you can't store it in a static field. In this case you can resort to a technique based on the String.Intern method. This method receives a string argument and searches the argument in the intern pool: if the search is successful, the method returns a pointer to the existing string in the pool; if the search fails, the method inserts the string in the pool and returns a pointer to the element just added. Here's how you might implement the ConnectionString property in the hypothetical data component to better leverage the intern pool:

' VB.NET
Dim m_ConnectionString As String

Property ConnectionString() As String
   Get
      Return m_ConnectionString
   End Get
   Set(ByVal Value As String)
      m_ConnectionString = String.Intern(Value)
   End Set
End Property 

// C#
private string m_ConnectionString;

public string ConnectionString
{
  get { return m_ConnectionString; }
  set { m_ConnectionString = String.Intern(value);}
}

The first time a given value is assigned to the ConnectionString property, the search in the pool fails, the String.Intern method adds the string in the pool and returns a pointer to the new pool element. If the same connection string is eventualy assigned to a different instance of the data component, the String.Intern pool returns a pointer to the element already in the pool and doesn't create any duplicate. The total amount of memory that the application uses is reduced and so is the number of garbage collections that occur during the application's lifetime.

I often need to paste a text fragment as a comment in my source code. Unfortunately I can't simply paste the text and then use the Edit-Comment Selectio command. because the Visual Studio editor - at least when working with VB.NET - tries to interpret the pasted text as code and it ruins its formatting, adds or deletes characters, and so forth. In addition to this problem, when I am preparing samples for my books I need to revise all CR-LFs in the text, to wrap longer lines, because Microsoft Press standards mandate that lines aren't longer than 92 characters. All in all, it's a real nuisance.

 

A few weeks ago I decided to avoid this waste of time and wrote a macro that would do the pasting and the formatting for me. It's a simple and tiny way to increase productivity, that allows me to focus on the things that really matter. If you like tidy code listings, I am sure you'll find this macro useful.

 

The first problem I had to solve is a limitation of the Clipboard.GetObjectData method. When invoked from a macro, this method always returns Nothing, thus I needed a different way to read the text in the Clipboard. I can surely do this with an API call or by calling a method in a separate DLL, but I thought that reading the Clipboard from a macro shouldn't be that difficult. My next attempt was based on the Paste method of the TextBox control:

 

' Retrieve the text in the clipboard

Dim tb As New TextBox

tb.Multiline = True

tb.WordWrap = False

tb.ScrollBars = ScrollBars.Both

tb.Paste()

Dim text As String = tb.Text

 

This approach works nearly always. Every now and then, in fact, the Paste method fails with a cryptic message: "Class already exists". I noticed that this error occurs only if the macro editor is open, therefore during the normal use it doesn't cause much trouble. However, once you get this error, the only way to get rid of it is by restarting Visual Studio. When I posted this first solution on my Italian blog, reader Andrea Ferendeles suggested a different approach, based on the Paste method of the TextSelection object:

 

' Read the text in the clipbard, through the Selection.Paste method. 
Dim sel As TextSelection = DirectCast(DTE.ActiveDocument.Selection, TextSelection)
Dim sp As EditPoint = sel.ActivePoint.CreateEditPoint()
sel.Paste()
' Select and read the text just pasted, then delete it

sel.MoveToPoint(sp, True)
Dim text As String = sel.Text
sel.Delete()

 

Once I solved this problem, writing the macro was relatively simple:

 

Imports EnvDTE
Imports System.Text.RegularExpressions

 

Imports CodeArchitectsMacros

 

   Public Sub PasteAsComment()
     PasteAsComment("80")
   End Sub

   Public Sub PasteAsComment(ByVal lineLength As String)
      Dim maxLength As Integer = CInt(lineLength)

      ' Read the text in the clipbard, through the Selection.Paste method. 
      Dim sel As TextSelection = DirectCast(DTE.ActiveDocument.Selection, TextSelection)
      Dim sp As EditPoint = sel.ActivePoint.CreateEditPoint()
      sel.Paste()
      ' Select and read the text just pasted, then delete it

      sel.MoveToPoint(sp, True)
      Dim text As String = sel.Text
      sel.Delete()

      ' Split in lines not longer than MaxLength
      Dim result As String = ""
      Dim currLineLength As Integer = 0
      For Each m As Match In Regex.Matches(text, "\S+\s*")
         If currLineLength + m.Length > maxLength Then
            result &= ControlChars.CrLf
            currLineLength = 0
         End If
         result &= m.Value
         currLineLength += m.Length
         If m.Value.IndexOf(ControlChars.CrLf) > 0 Then
            currLineLength = 0
         End If
      Next
      result &= ControlChars.CrLf

      ' Paste the text in the code editor
      sp = sel.ActivePoint.CreateEditPoint()
      sel.Insert(result)
      sel.MoveToPoint(sp, True)

      ' Comment and reformat it
      DTE.ExecuteCommand("Edit.CommentSelection")
      sel.SmartFormat()
   End Sub

End Module

As you see, there are actually two macros. The version with zero arguments creates comments lines that are 80 characters or shorter; this is likely to be the version that you'll use more often and you may want to associate it with a keyboard shortcut. The version with one argument allows you to specify the line length and can be used only from the Command window. For example, the following command pastes the current Clipboard content as comments not longer than 60 characters:

 

Macros.MyMacros.UsefulMacros.PasteAsComment 60

 

You don't really have to type all these characters each time, because you can associate the command to an alias. using this command:

 

alias PasteCom Macros.MyMacros.UsefulMacros.PasteAsComment

 

Once you've created the alias, you can recall the macro as follows:

 

PasteCom 60

 

---

NOTE: In case you never wrote a macro in your programming life, this is how to proceed:

 

1) run the Tools-Macros-Macros IDE command (or just press Alt+F11) to bring up the Macro IDE

2) in the Macro IDE, select the MyMacros project, then issue the Projects-Add Module to create a new module that stores all your custom macros then paste the macro code inside this module. (As in previous code, most of my macros are gathered in the CodeArchitectsMacros module.)

3) Go back to Visual Studio and display the Macro Explorer window, by means of the Tools-Macros.Macro Explorer menu command (or just press Alt+F8); in the Macro Explorer window, expand the MyMacros node and then expand the CodeArchitectsMacros module

4) optionally, go to the Tools-Options dialog box to assign a keyboard shortcut to the PasteComment macro

 

You're now ready to test the macro. Switch to Notepad or Word or wherever the text is, copy it into the clipboard, switch back to Visual Studio, place the caret where you want to insert the comment, and run the macro. You can run the macro by double-clicking its node in the Macro Explorer window, by typing the keyboard shortcut (if you assigned one), or by typing the macro's name inside the Commands window (with or without its alias, see above).

 

First of all, some background on delegate covariance and contravariance in C# 2.0. Let's suppose you have the following delegate definition:

delegate object GetControlData(TextBox ctrl);

Thanks to delegate covariance, this delegate can point to a method whose return value inherits from the delegate's return type. For example, covariance enables a GetControlData delegate to point to any method that takes a TextBox argument, regardless of its return value, because all .NET types inherit from System.Object. The only condition is that the method actually returns something, therefore the delegate can't point to a void method. For example, you can create a GetControlData delegate that points to the following method, because the String type inherits from Object:

string GetText(TextBox ctrl) 
{ return ctrl.Text; }

Delegate contravariance lets you create a delegate that points to a method whose argument is the base type of the argument that appears in the delegate's signature. In previous example, contravariance enables you to create a GetControlData delegate that points to a method that accepts a Control or Object value, because these types are both base types for the TextBox class specified in the delegate signature. For example, the GetControlData delegate can point to this method:

object GetTag(Control ctrl) 
{ return ctrl.Tag; }

It should be evident that covariance and contravariance don't impact code robustness and can't cause type mismatch errors at runtime. Obviously, covariance and contravariance can be combined, thus a GetControlData delegate can point to the following method:

string GetText(Control ctrl) 
{ return ctrl.Text; }

It's important to notice that - even if the target method accepts a generic Control instance - if you call this method through the delegate, you must pass a TextBox argument, because this is the type that appears in the delegate's signature.

You can find more details on what I've explained so far virtually anywhere on the 'Net, with many more examples. It's time to go back to the main reason for this post.

In case you wondered why I used C# for all the examples, here's the reason: Visual Basic 2005 supports neither covariance nor contravariance.

Is that absolutely correct? Well, yes and no. It's true because VB 2005 doesn't support these feature natively, but you can leverage them all the same. It isn't immediately apparent that covariance and contravariance are supported at the .NET Framework level. In other words, they are a feature of .NET 2.0 delegates, not just C# 2.0. In fact, in .NET 2.0 it is possible to use reflection to create a delegate that has both these properties. Here's how you can proceed if you code with Visual Basic 2005. Say you have the following delegate definition and the following method inside a Windows Form class:

Delegate Function GetControlData(ByVal ctrl As TextBox) As Object

Function GetText(ByVal ctrl As Control) As String
   Return ctrl.Text
End Function

VB 2005 doesn't support covariance and controvariance natively, therefore it isn't possible to create a GetControlData instance that points to the GetText method using pure VB code. However, you can get there anyway via reflection, by creating a MethodInfo object that points to the target method and then passing this MethodInfo object to the Delegate.CreateDelegate static method:

' the target method
Dim targetMethod As MethodInfo = Me.GetType().GetMethod("GetText")
' build the delegate through reflection
Dim deleg As GetControlData = DirectCast([Delegate].CreateDelegate( _
   GetType(GetControlData), Me, targetMethod), GetControlData)
' show that the delegate works correctly
Console.WriteLine(deleg(Me.TextBox1))

This code is only slightly slower than the direct creation of the delegate (that you can implement only in C# 2.0), but this is hardly a serious issue, because you typically create a delegate once and use it many times. Another minor problem is that this code can fail at runtime if the method name is mistyped, but on the other hand you would spot this bug the very first time you run the code.

NOTE: I haven't tested this code against the RTM version yet, but under the RC release I found the .NET support for covariance and contravariance isn't perfect. In fact, not all the overloads of the Delegate.CreateDelegate method support this feature. For example, the overload that takes the name of the target method (instead of the MethodInfo that points to the method) causes a runtime error (ArgumentException: Error binding to target method) if you attempt to create a delegate whose signature doesn't match perfectly the target method's signature.

I was so excited to announce the new version of the dotnet2themax site that I forgot to introduce myself, as is customary in any weblog. On the other hand, if you have attended dotnet2themax.com in the past, odds are that you already know me, perhaps because you've read one of my books or one of my articles on programming magazines. But I will summarize my professional life here, if only to provide links to other places where you can find more interesting material.

I live and work in Bari, Italy, but I often travel to speak at conferences such as VSLive!, WinDev (US), DevWeek (UK), TechDays (Switzerland), and a few others.

I am one of the two Italian MSDN Regional Directors and in the last two years I have served as the chairman for Windows Professional Conference, the largest Italian conference for developers, and routinely speak at DevDays and other Microsoft events in Italy since 1998. I have been giving classes for Wintellect in the US until mid-2004, when I decided not to spend abroad 5 or 6 months of each year.

In 2002 I founded Code Architects, a software company that focuses on .NET and Microsoft technologies, together with Giuseppe Dimauro (the other MSDN Regional Director for Italy). Code Architects provides training and consulting services for many Italial government agencies and large companies, including Microsoft. Code Architects markets a line of programming tools that I authored (or co-authored), including CodeBox, Form Maximizer, and the award-winning VB Maximizer. The Code Architects Team include some of the most skilled .NET experts in Italy. If you can read Italian, you might find a lot of interesting stuff in our Team Blog.

I wrote about 80 articles for Visual Studio Magazine (formerly Visual Basic Programmer's Journal), with which I collaborate since 1996, and also wrote a couple of articles for MSDN Magazine and for developer's sites such as DevX. For example, you can go here to read nearly 300 tips and short articles I wrote for DevX, mostly on VB6.

I don't write only for US magazines, though. I wrote my first article back in 1983, then I wrote dozens of columns for Computer Programming, the leading Italian magazine for developers. In 1995 I founded Visual Basic and .NET Journal (formerly Visual Basic Journal), the only Italian magazine entirely devoted to .NET Framework programming.

 

English

Italian

While I still am the editor-in-chief of my own magazine, in recent years I decided to write fewer articles to focus on my books and my own vb2themax.com Web site, which I founded in 1999 and that a few years ago was expanded into dotnet2themax.com to match the new C# and VB.NET contents. This site is now sponsored by Code Architects, together with the Italian web sites dotnet2themax.it and ugisharepoint.it.

Microsoft Press published my first book in 1999. Since then Programming Microsoft Visual Basic 6 has sold around 150,000 copies all over the world, including translations to Italian, Japanese, Chinese, Korean, and Spanish, and continues to sell more than many VB.NET books. In 2002 I wrote Programming Microsoft Visual Basic .NET, which the next year was upgraded into Programming Microsoft Visual Basic .NET 2003, a 1400-page textbook that cover virtually everything you need to know about VB.NET and the .NET Framework. It has been one of the VB.NET bestseller and as of today it nearly alwways appears in Amazon's Top Ten list for Visual Basic and .NET books. I also co-authored Applied Microsoft .NET Framework Programming with Microsoft Visual Basic .NET (with Jeffrey Richter) and the newer Practical Coding Guidelines and Best Practices for Visual Basic .NET and C# Developers (with Giuseppe Dimauro), a collection of over 700 rules and tips for writing robust and efficient .NET applications.

While Visual Basic is still my pet language, I write a lot of C# code as well. I am especially interested in programming techniques, algorithms, optimization, .NET internals, client-side (Windows Forms) and ADO.NET programming. I love to write addins, macros, code generators, and other tools that can make programming a more pleasant (and faster) experience, and I'll use this blog to share my findings with you all.

What else? I love music - a bit of everything, but especially jazz and fusion - and in my previous life I was even tempted to become a professional musician, until I realized that programming can be as much fun. I played my alto sax with many local combos and orchestras, but I probably reached by peak - on the fun side, at least - with Don Box's Band on the Runtime. If you are among the few millions who never listened to the Band, you can grab a video here or here. You can find some lyrics here and here.

If you're reading these lines you already know that we have completely renovated the .NET-2-The-Max site. We have a new layout, new material, and new blogs. We have less contents, too. Yes, we've decided to drop some sections from our site. Let me explain why.

When we launched the original vb2themax.com site in 1999 it was hard to find quality-level material on developers' sites. Most sites solicited tips and code samples from visitors and published it, in most cases without editing it for accuracy. Thus, we took the opposite route and decided to publish just our own material and only the best contributions from our readers. This approach and the fact that we have published new material each and every week for three years made our site very popular among VBers. (SQL Server Magazine put vb2themax in the top ten developers' site, together with first-class sites such as MSDN Online and DevX.)

More recently we lauched dotnet2themax.com. We dropped all VB6 contents to focus on .NET exclusively. The new site offered tons of links to external articles - that were categorized and searchanble, and enabled readers to filter both the index and individual articles' contents to see the material related only to VB.NET or C#. In spite of these new features, the site was basically similar to the original vb2themax and was conceived as a single-stop-shop from where developers could start their explorations.

Today, however, finding great contents on the Web is easier than ever. Most magazines are available online and for free, many Microsoft developers reveal all the .NET secrets in their blogs, and you can always use Google to discover programming gems hidden in a site or a blog you never heard before. There's no more need for a site like what dotnet2themax used to be. No need for topic categories and an internal search engine, for example. And above all, no need to update the web site on a regular basis, as if it were an online magazine.

In the new dotnet2themax.com site, Marco Bellinaso and I - and whoever will join us later - will be telling our discoveries in the .NET fields we are more familiar with, such as VB.NET and C# languages, programming techniques, ASP.NET, Windows Forms, Sharepoint, and optimization techniques. We will write our blog as frequently as possible, publish code samples and articles, upload our tools, and anything we think can be useful or interesting for you developers out there.

Happy reading!

Francesco