Why should I refactor my code? In fact, what is refactoring, and why should it concern me?
Refactoring is an organized methodolgy for changing the internal appearance and organization of your code without altering the external behavior, except as the refactoring may cause your code to perform better. There are several goals that I believe should be accomplished by refactoring. The following list is by no means exhaustive, but simply represent several thoughts that came to mind as I was writing this article.
Keeping your code modular
In my estimation, keeping your code broken into small modular, logical blocks of code is one of the most important principles governing good programming style. I would not want you to think that I always do this, but this is one of those cases where I suggest that you do what I say, not necessarily what I do. I have never worked with a progammer that didn't break rules in the heat of the battle to meet a deadline. However, if you tend to let your methods "ramble", as some people let conversations ramble, and some writers let their verbosity ramble (I'll try not to do that here), then you need to break that habit. Start thinking modular. Then you will start to write in smaller methods that perform one logical process of a much larger functionality.
This will shock some developers that have not sat under the tuteledge of a computer science professor (I didn't), but many have said that if a method exceeds twenty (20) lines of code, it should be broken into two methods. I'm afraid that few of us can claim that we often adhere to this standard. I do not belive that this should be a hard and fast rule, but it should be kept in the back of our minds as a worthy goal while we are coding. If you find, after you have completed a lengthy method, that it logically performs two or more logical processes in achieving its complete goal, consider stopping right then and breaking it into smaller methods. You will find that the code will be much easier to debug and in the long run much easier to maintan and modify. If you find yourself having to refactor huge methods, KnowDotNet has developed an inexpensive new product called NET Refactor. This product has a feature called Refactor Method which will make the work of breaking down large methods into a series of smaller methods a simple and almost automatic task.
Keeping Your Code Readable.
A couple of principles should be kept in mind here. First, keep in mind, that some poor programmer may have to revisit your code, even after it is debugged, for modifications. If you do not keep your code clear, when it gets "cold", it will be poetic justice if you are that poor programmer that has to try to figure out what a complex block of code is doing. So, for the sake of anyone who has to modify your code in the future, keep it simple. For example, deeply nested function calls make look neat when you write it, but they aree not easy to modify, and may not in fact run as well. I know that in earlier versions of Visual Basic, nested function calls were said to hurt performance, but I cannot speak for VB.NET or C#.NET. I am saying for the sake of everyones sanity, don't obfusciate your code in the name of being "way cool." Secondly, if the code is such that it is not immediately obvious what it is doing, write enough comments to at least describe what is being accomplished, without necessarily going into the details of the algorithm.
Another thing to keep in mind concerning readability is to keep your code lines short enough to stay in the code window. This is not always easy, especially with the verbosity of long, descriptive method names and many of the Namespaces and objects in the.NET Framework. But, that's why they implemented the continuation mark " _" in Visual Basic and continuation has always been unlimited in the C language because a C/C# line is completed when a semicoln (;) is reached, and the compiler ignores white space.
Always continue long procedure definition lines. For example, look at the readability difference of the following two lines of code. The following line will wrap in the browser, but you can imagine how far you would have to scroll to see the whole line of code. Remember, it takes time to scroll, and time is money.
| Private Sub CollectLocalVariables(ByVal procCode As String, ByRef varCol As VariableCollection, ByVal j As Integer, ByVal linesToScan As Integer) |
| Private Sub CollectLocalVariables( _ ByVal procCode As String, _ ByRef varCol As VariableCollection, _ ByVal j As Integer, _ ByVal linesToScan As Integer) |