Pet peeves about directory and file referencing

Since starting at Microsoft I have had to review a lot of code - both in code reviews and when debugging others' tests.  Like most other people I have my pet peeves and nitty gritty details.  For instance, instead of writing

if

(somevariable == null)

 I often recommend that people use

if

(null == somevariable)

How does this help you? Well, if you accidentally type

if (somevariable = null)

You will assign null to somevariable - probably not what you wanted to do. Yes, I do know that the C# compiler will warn you about this but languages such as C and C++ will not be so forgiving. However, if this piece of code is reversed so the null is on the left hand side the compiler will always generate an error because null cannot be assigned a value.

That, however, is only a small detail and is a matter of coding style. My biggest pet peeve is when I see code that looks like the following

string

fullFilePath = path + "\\" + fileName;

Why is this a problem? What if the variable path already has a backslash? If that is the case the path will be invalid and an error will occur at runtime. The .NET runtime makes quick work of situations like this

string

fullFilePath = Path.Combine(path, fileName);

The Path class is available is System.IO and contains many other useful methods - all of which are documented in MSDN. One of my other favorite methods is Path.GetTempFileName() - which returns a path in the user's temp directory - the only place where you are guaranteed to always have write access. Getting back to the code above isn't it much cleaner? In this case Path.Combine takes care of all of the possibilities for you - you no longer have to worry about the backslash in the file name. One time I saw code similar to the following

bool

result = SomeMethod(data, someDir + "\\");

Now this is just plain ugly. Here we are calling a method that depends on the directory name ending with a backslash. This is just asking for errors. This can be fixed by rewriting SomeMethod to use Path.Combine to handle the backslash.

Another problem with hard coding the backslash is several localized OS's do not use the backslash - for instance the Japanese OS uses the Yen sign. Of course the .NET Path class will handle this for you - it even has a property that returns the separator character for the current system if you are interested.