Misuse of the unary-not operator (!)

Coming from a background in C Programming, I am very familiar with the "!" or unary-not operator. This operator inverts the value of the operand it is applied to, so that a true operand returns false, and a false operand returns true. As a programmer often involved in the maintenance of other people's code, I am also very familiar with wading through pages and pages of software that appears little better than hieroglyphics.

Unary-not was widely used back in the days of C, and C++ to an extent, because the language didn't have a built in "null". Some programmers or libraries would use "0" as the null, some would use "-1". There was no consistent way to check if a condition was true, so unary-not did the job.

These days, in "modern" languages such as Java, C# and VB.NET we have the null value, which is assigned to any reference type variable by default. This means that we can write sensible statements like this:

if (myReferenceType != null)
{
// do something
}

I like code that says exactly what it's doing - in the case above, it says "if myReferenceType is not null, do something". Consider the unary-not approach

if (!myReferenceType)
{
// do something
}

Reading that out, we have "if not myReferenceType, do something". What does that statement mean? It doesn't make sense when you read it. What if the unary-not operator has been overloaded?

Unary-not is often also applied to boolean values. Which allows us to do some frankly nasty things. Consider the following:

if (!myClass.IsAvailable())
{
// do something
}

"If not myClass is available, do something". If myClass isn't available, do something. Now consider:

if (!myClass.IsNotAvailable())
{
// do something
}

"If not myClass is not available, do something". If myClass is not not available, do something. Or even:

if (!myClass.IsAvailable()==True)
{
// do somsething
}

"If not myClass is available is true, do something".

As you can see, we can weave all sorts of syntactical loops that are difficult to get out of. Whilst the choice of names for method calls is important (and I will focus on that in a later post) the unary-not operator is causing problems.

Part of the issue with unary-not is that it doesn't preclude the programmer from using it with other logic operators - so you can, as above, combine it with a method call that you are comparing against a boolean value, and invert the result of the entire statement to produce your eventual value.

My final beef with unary-not is that it's very difficult to spot. Unlike an "==False" or a "<>0" it hides itself at the start of a statement, as far as it's possible to get from the functional parts of the code. As a maintenance programmer it is easy to miss, and of course it changes the whole idea of what you're reading.

For your own good, and for maintenance programmers who come after you, don't use unary-not!

Subversion is no Clearcase

I have recently begun a consulting stint with a large firm that is using Subversion (SVN) for its source code control system. This is the first time that I've used SVN in anger, although I've heard a lot about it - all of it positive.

SVN is the first time I have used a piece of version control software that uses the Modify-Commit model - that is, you can modify any file under version control, but you have to Commit those changes before they become part of the file's history. This model is also used by CVS, on which SVN is based.

The alternative to Modify-Commit is the Checkout-Checkin model, where a file has to be explicitly set for writing, or "checked-out", before it can be modified. The file is then "checked-in" to store the changes in the file's history.

It has taken me a while to get used to the M-C model, and I don't really like it: I like to have files set to read-only until I explicitly say that I want to edit them.

Another difference between SVN and Clearcase is the repository-wide versioning model. If you modify a single file in SVN, and then commit that change, a new version number is applied to the entire repository. Files that are completely unrelated to the change are marked with a new version number. This makes the revision graph virtually useless. In contrast, the Clearcase version tree browser is the most useful piece of functionality I have ever come across.

The merge-comparision and conflict resolution tools in SVN are pretty dire, far less intuitive than the Clearcase "merge manager" (or "merge mangler", to its friends).

The biggest problem I have with SVN, however, is the branching model. When creating a branch, and doing a "checkout" to get the latest files, it is far too easy to create your files in the wrong directory structure, since SVN doesn't enforce any kind of directory level on you. In contrast with Clearcase, where any static views are created in "C:\Clearcase\vob-name\". This is one occassion where I'm happy to trade flexibility for consistency. I need to know that the half-hour checkout process I'm about to undertake is going to end up in the correct directory.

Clearcase allows you to create branches from any point in your source-code repository and then merge them back into your "main" branch. Likewise, SVN allows you to create branches from your "trunk" branch and then merge them back in. SVN, however, doesn't properly version the directories themselves. This means, for example, if you add a new file ("newfile.cs") to your branch directory, and then merge your changes in to trunk, "newfile.cs" does not appear. Instead you get the error "Skipped missing target". I haven't yet figured out how to get new files merged from one branch to another, short of manually copying the files and then adding them in.

My final issue with SVN is one that applies to most open source software, and that is "fitness for purpose". I have managed to get SVN to tie itself in knots a couple of times, which have meant I've had to delete the .svn directories, back up my changes, re-checkout and then apply my changes manually. Basically, the SVN equivalent of a "blue screen of death". That is OK if I'm working on an personal project, or perhaps in a very small team on a limited codebase. Unfortunately, on a global project, with millions of lines of code, and teams of developers working in different, to sometimes differing agendas, it creates chaos. Also, the documentation available is very limited, and in some areas it is non-existent. More-than-trivial-branching is one area where I feel I am "writing the book" on it. Again, that's fine in a personal/amateur environment, but at the enterprise level it is simply not sustainable.

SVN is OK, and as a piece of software I am sure it is a great technical achievement, but it is not an enterprise level source control system, and it should not pretend to be one. In the final analysis, SVN's shortcomings are not the fault of SVN or its programmers, they are the fault of the decision-makers who decide to take an amateur open-source product and trust a multi-billion dollar firm's entire codebase to it.

Fun with Subversion on Windows

Windows isn't case-sensitive when it comes to filenames. The Subversion Repository, however, is. If you add a file called "FILE.cs" and then replace it with a later copy, but called "File.cs", you'll get two files in the Repository. However, if you try and do an SVN Update on a different machine you'll get an error.

The solution is to go into the Repository Browser, delete both FILE.cs and File.cs, and then re-add your updated file.