Dear Developer Express,
I've been using your C++ refactoring tool for some time now, mostly version 2.2.2. First, I'm going to give you the good news. I've tried out your competitors and you've got the best C++ refactoring support. SlickEdit wants me to change my entire IDE just to get refactoring support and I'd rather keep using the IDE I already know. Ref++ doesn't provide any way to evaluate their product without buying it, so I gave them a pass. Eclipse currently only supports Rename, although its IDE wasn't so hostile that I'd be willing to use it for C++ refactoring if it had better or comparable refactoring support when compared to a commercial tool.
Now, the bad news. To be frank, the quality of the C++ support is very weak. There are numerous fronts on which the quality of lacking and I'll go into these individually. However, the overall impression I get is that C++ support was tacked on as an afterthought, particularly native C++. The product seems infected with "manageditis" in that it always wants to insert managed C++ code idioms, or replace my existing native code with managed C++ code idioms. To be honest, most of the people I know who write managed code use C# or even VB.NET and not C++. Most of the people I know using C++ are writing native code, possibly for portability reasons among target platforms. So when your tool keeps assuming that "C++" is equivalent to "Managed C++ for .NET", you really are barking up the wrong tree. Most C++ code bases are legacy native code bases and not new greenfield development for Managed C++ for .NET. This is just one example, but the trend repeats itself throughout the documentation which doesn't make it clear if or when refactorings are available in C++. The same trend follows through all of CodeRush where most of the templates assume I'm writing managed code and insert code that isn't relevant for native C++.
Documentation: I have to say I'm not too fond of the documentation. I'd rather have documentation integrated into VS.NET's help facility than have to navigate your odd "Guide" window. (I just found a bug in its rendering display in 2.5.0 today, while trying to use it.) Its just different, its not an improvement. In particular, a lack of a comprehensive table of contents makes navigating the document tedious and painful. Important information is hidden on pages that have no TOC entry and you have to wander through the other pages in order to find a link to the information you want. Second, the information in the help pages themselves just isn't very clear most of the time. In particular, the context in which refactorings are supposed to be available is vague. Instead of a terse description, there should be examples showing where every refactoring applies. Today I tried browsing your Guide in order to try and understand how I would add editing support for a new language to VS.NET (syntax highlighting, coloring, supply my own refactorings, etc.). The current organization of the information makes it very difficult to understand how to even start such a task. Although I've browsed your web site(s) and forums, I just don't find this information readily available. It could be that its hidden in there and I'm missing it, but if after searching for some time and not finding it, I'd say that's a documentation bug, particularly if the information is in there. Information from help files should be easy to find and not require me to go sleuthing.
ReFactor!Pro: In a short while of using this product, I have found over 50 serious bugs. Yes, I've reported them all to your support department, but finding this many bugs -- even in simple and common refactorings like Rename -- is disconcerting. Again, it just feels like the C++ support hasn't even been tested except with baby food cases that always work. This past weekend I did something very simple to test ReFactor!Pro. I just sat down in front of a blank source file and attempted to type code that would allow me to exercise each and every refactoring listed in your documentation that could apply to C++. I ended up filing bugs on almost every refactoring that I tried. This is not creating torture cases and finding obscure endpoints, this is just exercising the basic functionality offered. In addition to bugs, there have been performance problems almost constantly. When I asked about this, the first response I got was an implication that my machine was underpowered for using this tool. At the time I had 512MB of memory and it was implied that this just simply wasn't enough and my machine was swapping all the time, causing poor response. To be honest, I was skeptical of this claim, for it was the CPU that spiked when using your products and not the disk drive. Even running perfmon and monitoring .NET garbage collections didn't indicate excessive garbage being collected. So I upgraded my laptop to 2GB of RAM and nothing changed. Your product still made navigating source files noticeably more sluggish than before. When 2.5.0 came out, the CPU spikes were so frequent that I couldn't even navigate a source file without the CPU spiking on every press of the down arrow key. Your support department did give me a workaround, but honestly how can something go out the door with such a problem? This was not a developer nightly build I was using, but the officially released version of the product on the web site. This is normal activity for a developer in Visual Studio and I can't see how this would go without notice if the product was tested.
CodeRush: Because ReFactor!Pro had such performance problems, I didn't install CodeRush until later. Just like Intellisense, its a wash as to whether or not this was a productivity increaser for me. Most of the time I end up in a situation where I could have simply typed the correct code in less time than with CodeRush. The problem is that CodeRush keeps inserting extra stuff if I just type the code normally. Then I have to go back and change what CodeRush inserted, or slow myself down by constantly pressing ESC to dismiss whatever CodeRush wants to insert. If I was a hunt-and-peck style typer or slow or poor typer, then CodeRush would certainly be of benefit, but for someone who has been touch typing for nearly 30 years its simply noise that gets in the way most of the time. I think the one that was particularly eggregious was the binding of normal '(' and ')' to apply automatic parenthesis pairs whenever typed. Amazingly enough, typing just one half of a parenthesis pair is extremely common when editing code. Having your tool always inserting the "other half" that isn't needed was quite annoying. I eventually changed the key binding to something that required another modifier key (Ctrl, I believe), but honestly -- you shouldn't ever put magic insertion code bound to normal punctuation that you use all the time in a programming language. I should just be able to type code unmolested at any time.
DXCore: This technology seems really promising, but where are the docs? Where are the tutorials? Where is the information that shows me how easy it is to do something more than what a VS.NET macro can achieve? I think I can dimly see the potential through the mist, but the provided information in the "Guide" is weak at best. I further become disappointed when I drill through links on your web site that take me to a Wiki for DXCore that is so empty even the logo image displayed on every page hasn't been configured. Is this thing for real? It seems like I might be able to do great stuff with this, if only I could get complete and accurate information about it along with examples.
Finally I want to say that the point of this letter is not to slap you in the face, but to bring these problems to your attention in a manner that an individual bug report cannot achieve. ReFactor!Pro has been of assistance to me in refactoring a large C/C++ code base. However, I've always had to second-guess each new scenario in which I use your tool because the quality of the results is always somewhat suspect. A refactoring tool has to be automatic, reliable and always generate semantically equivalent and syntactically valid replacement structures. When you can trust the refactorings, you can do so much more with the product. When the refactoring results are suspect, you end up relying on the tool less.