Learning to live with the squiggly line
My name is Bil Simser, and I'm a ReSharpaholic.
There. I said it. I'm addicted to ReSharper in a very heroin-like dependency way. I refuse to work without it. Yes, I will actually turn down contracts if the firm doesn't provide or forbids me to use my own copy of R#. To me my value to a customer is providing the maximum productivity that I can and to me that productivity comes from using this tool.
I know it seems wrong to depend on a tool like this but it's reality. The way I code works perfectly within the way R# aids me in being productive. It grants me a fluid motion to refactoring and code efficiency and helps me get into a groove when I code. A groove that is both productive and efficient and fun. That keeps me going throughout the day. No longer do I have to worry about namespaces, or perform manual acts of extracting interfaces, pushing methods up to base classes, or creating classes. I don't get bogged down finding classes or files and I've almost abandoned my mouse.
However being so dependent on it I'm now at a crossroads. Visual Studio 2008 RTMs later this month and I was looking forward to using it. It's faster and seeemingly better than it's 2005 counterpart and works well (at least throughout all the beta testing we've done on it). R# provides a version for VS2008 however it's lacking some major compatibility not with Visual Studio but rather the underlying CLR, namely version 3.0. This means that if I choose to move to VS2008 and R# 3.x I have to live with squiggly lines in my code whenver I'm writing LINQ, lamdba expressions or extension methods (to name a few examples).
What are these squiggly lines you ask? Take this screenshot for example:
Here you see things like "lot" underlined with a squiggly line (I'm sure there's a more technical term for this) indicating there's an error of some kind. Sometimes it's as simple as a syntax error, other times it's the wrong type being passed to a method. This helps tremendously combined with the right gutter indicator that shows there's something amiss in your code. You can immediately just jump to the spot and fix it. This is insanely useful as I like my code clean. Squiggly lines are dirty to me and mean I have to do something (and you can see without them, how would you know something is wrong until maybe compile time [maybe]).
Unfortunately things like extension methods in .NET 3.0 are alien to ReSharper, and will be for some time now. Extension methods for example allow you to extend a class (any class including string or object or your own) and enhance it. For example here's some code from Scott Guthrie that extends System.Object by adding a method called "In" to it:
This allows me to write code for example like checking if a particular ASP.NET control is within a container control collection:
However in the declaration of the "In" extension method, ReSharper is going to show it's squiggly lines as it doesn't understand "In(this object o, IEnumerable c)". It'll consider this a syntax error and indicate this in the right gutter column. This seems dirty to me. It makes me feel like I've got something wrong in my code and I need to react, but there's nothing wrong here. These aren't the syntax errors you're looking for. Move along.
So it's a toss up between using VS2008 and 3.0 projects and living with squiggly lines, or not. On the flipside, stick with 2005 and just wait until JetBrains comes out with version 4.0 early in 2008. The other alternative is to use VS2008 but not write 3.0 code (or the features that ReSharper doesn't support yet). However that in essence makes me feel like I'm restricting myself because of a tool. Not a corner I like to be in but I seem to have painted myself there.
While I understand we're talking about two different companies on two different schedules here, it bugs me. Maybe you'll say "Suck it up Princess" and deal with it. After all, the code will compile it's really only the UX inside the IDE. However to me that's important too as it makes me stop and wonder, did I miss something? Do I need to stop and do something extra here? Maybe it's not the same for you but for me it's a question I'm pondering which is making me think about this. YMMV.
Update: Ilya Ryzhenkov, the .NET Tools Product Manager at JetBrians, posted an update in the ALT.NET mailing list with some information about ReSharper 4 and C# 3.0. While this isn't "official" information, it might be useful in making decisions:
"It is not possible to convert C#-2.0 "brains" of ReSharper to semi-C#-3.0. Also, it doesn't make any sense. Not only new constructs appeared in new version of C#. There are many changes in type inference, symbol binding and other very internal things. Even if we just parse the syntax, we will not be able to resolve overloads because we can't infer the type from, say, lambda. It will still be all red code. Refactorings and other features will break all the time, because they should be updated to support new constructs. Feature as simple as Expand Selection should be updated to work consistenly.
Even now, when we have ReSharper 4 in development and it parses almost all new constructs (we use C# 3.0 actively), and even (almost) fully supports "var", extension methods, object and collection initializers, implicitly typed arrays, autoproperties - it is still a pain to use ReSharper with C# 3.0. We are working hard to make it consistent and support language in its full power, but it's going to take time.
Also note, that EAP builds will be available pretty soon, December (optimistic) or January (more realistic). So you will not have to wait for 4-6 months, if you are going to jump pre-release wagon and provide us with your invaluable feedback."