Jay Bazuzi's coding blog

Single-line blocks: A radical view

2010-06-16T00:02:00.000-07:00

For a long time I've been a staunch advocate of using braces around single-line blocks in C-like languages:

   // OK
   if (foo)
   {
   return 1;
   }

   // Bad
   if (foo)
   return 1;

The obvious reason is to protect against this kind of bug:

   // very Bad
   if (foo)
   Debug.WriteLine("returning 1"); // added later
   return 1;

There's actually a bug in Visual Studio that we shipped because of this kind of mistake. If memory serves, it was in VS 2002. The repro:

Start debugging.
Open the watch window
Make a Remote Desktop connection to the session running the debugger

Result:

The font in the watch window changes to the system font (big & ugly).

The problem here was a bit of code in DllMain of a debugger DLL where a single-line block didn't have braces, and then another line was added later. Turns out DllMain gets called when connecting in a RDP session. The Watch Window font gets deleted prematurely. This was in the early days of Terminal Sevices / RDP, so it took us a little while to get cluefull (opposite of clueless!).

It would have helped if we auto-formatted our code, but we didn't like what the C++ auto-formatter did by default, so we didn't run it.

Since then, I have argued that all single-line blocks must have braces, to prevent this kind of bug.

Later I started reading about Extreme Progamming, and their radical views on simplicity. I decided that simple, single-line blocks are a nice goal, because they mean your code is simple. So, I now have an exception to my rule. A single-line block can skip the braces if 1) it is on the same line as the if/for/whatever statement, and 2) the whole line is short. Also, I consider this state of affairs is particularly desirable.

So:

// Good

if (foo) return 1;

else if (bar) return 2;

else return 0;

A way to manage extension methods in C#

2009-01-06T11:39:00.000-08:00

I like C#'s extension methods, but I'm concerned about "polluting the namespace". I'm not the only one. I'm especially concerned about extensions to "object", as they appear everywhere. They can be useful, but wow that's a big impact. How to make valuable, wide-reaching extension methods possible without affecting lots of code that doesn't need the extension?

I've come up with an approach that helps me be picky about which extension methods are available in which contexts. That helps me manage how much pollution I am willing to accept. It is also means that most of the extension methods available in a given context are the ones that are relevant to the code I'm trying to write in that context.

Example:

namespace MyProject.Extensions.TypeExtensions
{
    static class _
    {
        public static bool DerivesFrom(this Type type, Type baseType)
        {
            while (type != null)
            {
                if (type.BaseType == baseType)
                {
                    return true;
                }

                type = type.BaseType;
            }

            return false;
        }
    }
}

Which is normally used like this:

    using Extensions.TypeExtensions;

    var typesDerivedFromFoo = from type in typeof(foo).Assembly.GetTypes()
                              where type.DerivesFrom(typeof(Foo))
                              select type;

Consequences

* That this approach works best if files are small, which means that my classes need to be small, too. If all your code is in a few files, there's no point to my method.

* All my extension methods are in the Extensions namespace.

* It's not friendly in languages that don't have extension methods. (You have to use the full name of the extension type):

Extensions.TypeExtensions._.DerivesFrom(type, baseType)

This isn't beautiful, but let's compare it to what you'd write if you didn't use extension methods at all:

TypeExtensions.DerivesFrom(type, baseType)

There is only an extra "_." and an extra "Extensions.", which isn't that much.

* My approach prevents you from using these methods as if they weren't extension methods, the way we did before:

using Extensions.TypeExtensions;
_.DerivesFrom(type, baseType);

Because "_." is ambiguous as soon as you bring in more than one extension.

* While C# requires that extension methods be defined in a class, the language doesn't care what the name of the class is. My approach reflects that, by giving the class a "nothing" name (and using the containing namespace as the visible name).

* The word "Extensions" appears twice in the namespace name, which is repetitive, redundant, says something that was already said. I'd rather call it "Extensions.Type", but that means that the name of type I'm extending ("Type") isn't available - I have to say "System.Type". Maybe that's a better choice.

Version control that scales down: Mercurial

2008-11-11T12:04:00.001-08:00

Version control that scales down: Mercurial

When working on a small software project for myself, I still want version control, but I don't want the overhead of, say, TFS.

I decided to give Mercurial a try, and it seems to scale down very well. Here's what I have done:

Install TortioseHG
Open a PowerShell Prompt
Go to the directory that contains my source
hg init # create a new "repository"
hg addremove # add all files in the current directory
hg revert # avoid adding files you don't want
hg commit

A good idea is to create a .hgignore file to tell it what files you don't want to add, if there are some. For a small C#/NUnit project, mine looks like this right now:

syntax:glob

*.suo

*.user

bin\

obj\

TestResult.xml

NUnit.VisualState.xml

Then, to add this file, do hg addremove, then hg commit.

Then, you just edit your files as needed. When you're ready to commit, you do hg addremove, hg commit.

I don't have to worry about keeping my filesystem and my project in sync with my source control. It just does it.

In another directory I have some PowerShell scripts. Since I already had Mercurial installed, it was easy: hg init, hg addremove, hg commit. Tada, it's under version control.

Things I like about Mercurial:

No server setup
No need to decide where on the server your files should live
No need to "check out" a file before you can edit it - adding version control doesn't interrupt your existing workflow.
Works offline just as well as online

Mercurial has a lot more power if you want to scale up, with rich branching & merging. You can create a branch for an experiment or a 1-off bug fix release, all offline. That's cool, but right now that's not important for me: I really just want to track my changes.

The main thing I wish for, and it's pretty minor, is PowerShell cmdlets. They're really nice to work with. I don't expect them to appear any time soon.

People often look to version control software to provide backups of their source code. I only have Mercurial on one machine right now, and standard guidance says I should put the small Mercurial server on another machine (my Windows Home Server seems like a good choice), and "push" my changes on to it regularly. I'm not doing that, because my changes are backed up in other ways:

The directory that contains all my source code projects is in a Windows Live Mesh folder. That means it's backed up, even the full history, unless I accidentally delete the whole thing.
Every night my computer is backed up to my Windows Home Server. Even if I delete by accident, I won't lose much.

I'm not sure how well mesh & Mercurial will get along. If I sit make edits on computer A, and Mesh syncs to computer B, I could commit from B, and that will get synced back to A. That isn't what Mercurial is intended to do, but I can't think of a reason it wouldn't work. The idea of being able to go computer hopping without having to first commit, push or pull, merge, commit each time seems attractive.

Backup up your pending changes (TFS)

2008-11-11T07:34:00.000-08:00

More than once I have destroyed my data by accident. I've certainly lost more data this way than any other. Version control is great for a lot of reasons; having a backup is just one of them. But if I have changes that aren't checked in, they are at risk. When I was working with TFS for version control, I wrote this PowerShell script to back up all my changes to shelvesets. TFS has the ability to enumerate all workspaces, so it's easy: you just run it once and it will back them all up. The shelveset names begin with "ZZZ" to sort them to the end of the shelveset list. It makes sense to run this as a nightly scheduled task. The script is also interesting as an example of how to manipulate TFS from PowerShell, via the TFS APIs, instead of trying to parse textual output:

[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Client")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.VersionControl.Client")

$localWorkspaceInfos = [Microsoft.TeamFoundation.VersionControl.Client.Workstation]::Current.GetAllLocalWorkspaceInfo() | where { $_.Computer -eq $env:COMPUTERNAME }

"Found {0} workspaces to back up" -f $localWorkspaceInfos.Count | Write-Verbose

Download:

Warning: it has been a year+ since I last ran this script, and I don't have access to TFS these days to test it. I think it works, but YMMV.