I've been doing some refactoring code recently and want to share some tips and tricks that could help developers in future efforts. These are just suggestions so feel free to use or ignore any of them, but keep in mind that they would make things a little easier for everyone in the long run.
Temp Files and Paths
I've seen in a few places that developers have been placing files into the C:\temp directory. Nothing wrong with this; however did you know that .NET makes it a lot easier now?
Before: string fullFileName = @"c:\temp\" + someFileName;
The main problem here this is that it assumes that the "c:\temp\" directory exists and if you want to change it we have to recompile the source code.
After: string fullFileName = String.Format("{0}{1}", Path.GetTempPath(),
Path.GetTempFileName());
The "Path" class in .NET will gives you lots of extra options for dealing with folders and files. The "GetTempPath" method will return the value set in the %Temp% environment variable which is default in Windows. "GetTempFileName" will give you a random filename which can be very handy if you are creating temp files. Another handy methods are "GetFileNameWithoutExtension" which means you can add any extension you want to a file.
Getting rid of old code
You all know how much I *hate* to leave old code hanging around, but leaving an entire classes really gets me going! The current Framework is chock full of classes that are old, duplicated or simply in need of a serious rewrite, but we can't delete them as there is the ever present "Possibility" of breaking the old ASP code. To address this we can use the "Obsolete" attribute to show a class should no longer be used.
[Obsolete("This class is a deprecated! use Company from DataAccessObjects Namespace.")]
public class Company
{ ...... }
We can also say something like this [Obsolete("This class is a deprecated and will throw a compile error!", true)]. This is Visual Studio will generate a compile error, but it's probably not something you'd want to do unless you really wanted to spend a long time testing.
Never..Never.. Never.. Swallow Errors!
I've seen this type of code all over every project and it's really bad practice.
try { someCode;
someMoreCode; }
catch (Exception e) { }
AAGHHH!!! having a catch with nothing in it is like driving drunk with your eyes closed and having no insurance, it's just saying "If I crash, just keep going and leave all that damage for someone else".
try { someCode;
someMoreCode; }
catch (Exception e) { throw new e;}
This is a little (but not much) better than the last example; least this this we acknowledge that a problem took place. The problem with this approach is that as we're throwing a "new e" so we actually loose the strack trace and if the error is deep in the bowls of the code you'll have a hard job finding the cause.
try { someCode;
someMoreCode; }
catch (Exception e) { throw;}
This will give you both the error and the stack trace, but really at this point its probably easier to just say:
someCode;
someMoreCode;
So what's the moral of our story? NEVER have a try-catch block unless you actually need to do something with it, log the error, throw a different error, it’s up to you but please do something in the catch block.
Creating Projects in the right folder
A very minor thing on the list is to keep an eye on the directory when you're adding a new project to an existing solution. By default if I was to add a new project to a solution it will go under the root folder. There however a text box on the New Project dialogue which gives you the option to add a subdirectory name.
