Comments to an article in Paul Vick's blog

Mr. Paul Vick himself has a blog. He wrote about the possibility of introducing some automated refactoring tools for VB.NET in Whidbey, and he asked for feedback. I am feeling the same courage I used to feel during the glorious old days of the dotnet list:

Paul,

I am willing to know which name the team will chose for these tools. However, unless it is something really better, I see no reason not to stick to "refactor". Any well informed VB.NET developer should know what it means. Otherwise, well, we know with knowledge comes power. I think it is perfectly natural to expect that some will disregard this feature at first as many are disregarding things like inheritance right now.

In my opinion most refactoring concepts are language agnostic, and there exist some projects in which multiple languages are involved. So, maintaining some consistence among all the .NET languages could have some value.

Regarding the importance of each feature, I have zero knowledge of refactoring academics, but I have had experience doing refactoring of some ugly VB code, both mine, and other people’s code I had to take over.

I am listing the refactoring tasks I usually perform manually in order of importance for me. I know some things are too complex to automate but any help in those would be great:

0. A customizable code beautifier: I know this is not in the list, but I usually need it before I start any refactoring work, especially if it is other people code.

1. To infer a super class and maybe build a factory pattern from similar classes that were created by copying and pasting: This is probably one of the difficult tasks to automate, but it is one of the most time consuming and rewarding in my experience. In Visual Basic it is very common, probably because the lack of inheritance in previous versions forced developers to copy and paste a lot. The output of this operation is usually cleaner, more debuggable and more extensible code, hopefully less bugs and fewer places to look for them. The main risk of doing this without any help is that the littlest oversight can lead to introducing unexpected behavior. How could the IDE help? I think it could include a side by side source comparison tool. I usually work with Beyond Compare which is superb.

2. Move member to other class: Useful when you find that most of the members a method is accessing belong to a different class. I often end up realizing that the method also belongs "semantically" to the target class. When I finish moving all methods to the appropriate class, I evaluate the remaining public members for a chance to private scope. The expected output is better encapsulation, and probably shorter code. This works likewise with methods, properties and fields.

3. Changing ADO Recordsets opened for sequential access to ADO.NET DataReaders in the middle tier. I know this one qualifies as a migration task, but I wonder if you could come up with a simple tool that does this. I have found this to be very time consuming, too complex for a simple search and replace, but too stupid to waste programmer hours in it.

4. Switching from “On Error” to structured exception handling: I am not sure how easy it is to map those things, and I know “On Error” is still valid. But using try - catch blocks is so cleaner! I usually do this manually and it can be time consuming.

5. Wrap “this” with try – catch block. Well, this one is not strictly refactoring, but it is related to 4.

6. Encapsulate field.

7. Symbolic renaming: This is important, but I think a simple search & replace will cut it 70% of the time.

8. Change method signature.

9. Global type replace: This may sound stupid but this can be useful when you decide to replace all instances of class A with instances of class B. A tool could analyze which members of class A are being accessed and offer a screen to map them to members of object B. The rest could be accomplished manually.

10. Extract method.

11. Inline method: opposite of extract method, useful when you find the method is used many times but only from a few places and you can't find a good name for it ;)... I mean, you realize that having it separated is not clarifying but obfuscating the code.

12. Replace multiple calls to invariant function with temp.

By the way, I like the idea of having “Change to”.

(I had to correct some mistakes I made in the original comment to his weblog)