Skip to main content

Ye old faithful IDE

Posted by kirillcool on January 18, 2007 at 10:03 AM PST

My current work project involves extending an existing application and adding a few new features. All is well and good, but it's written in C++. Well, all is still well, since that has been my primary development from '99 to '02 (in Visual Studio 6). The code is written well, the original developers sit right next to me, C++ is very much like Java (thankfully they didn't use operator overloading), so what's the problem?

Well, it all begins with the build configuration. Since there's no such thing as an Ant build script, you have all these in the project files (.sln and .vcproj). Now, the structure of these files changes between different Visual Studio versions, so if you want to upgrade to Visual Studio 2005, you'll have to upgrade your projects files as well. In this specific case, this is way over my head, since the build portions are very complicated and it would take too much time to port it to VS 2005.

So, i'm stuck with 4-year old IDE. Now, back in the day (VS 6.0), i didn't notice it, but now, coming back from Eclipse / NetBeans / IDEA, this looks like an old relic from The Stone Age. Refactoring? Not yet. Find all uses? Not yet. Set breakpoint on field change? Just follow this sequence of 7-8 steps that involves writing down the field address and typing it later in some obscure screen. And the list goes on. Personally, i came to depend so much on key strokes in Eclipse, that coming back to an IDE that doesn't have the matching functionality is a serious shock.

Now, this is obviously not a VS problem. This would be the same with much earlier versions of Eclipse, NetBeans and JBuilder. It's just that the coding doesn't really flow. If you want to add a new parameter to a method and change all the callers, you have the following options, none of which are very attractive:

  • Ctrl+Shift+F (Find in Files) for the method name and hope that no other class defines the same method name. Depending on the soltion size, this takes some time (the results are not cached by IDE).
  • Change the .h and .cpp by adding a letter to the method name, build the solution and see all the places that have been broken. Depending on the solution size and build target complexities, this takes even more time.

With this, an extended "Thank You" goes to all Java IDE developers that continue adding new features to their IDEs. It's only when we stop using them, we can fully appreciate their advantages.

Related Topics >>