C# Edit & Continue vs. Refactoring
Sean asks for it, and Andy blogs some of the thinking behind no E&C for C#.
I really like using E&C when writing C++, and I know that VB users find it pretty valuable. Seems strange that we wouldn't have it for C#, yeah? When we talk about the different kind of users of VS, the VB users are typically at one end of the spectrum, C++ at the other, and C# somewhere in the middle. So if E&C is good for the ends, isn't it good for the middle?
Yeah, C# users want E&C. So why don't we have it?
E&C was on the list at the start of the Whidbey cycle.
Refactoring was, too, but treated oddly. Every time we discussed the proposed feature list, we would have to talk about what refactorings really were, and whether they were worthwhile. Sure, being able to create a function from a bit of code is neat, but it seemed like something users can already do on their own. Why do they need us?
Then we looked a little more closely at some of the other modern editors our there, and saw users talk about how valuable Refactorings were. We even saw users choosing to write in Java over C# because of Refactoring support! Ack! We also read Fowler & really began to understand the importance of Refactoring.
When we sat down to look at Refactoring and E&C seriously, we realized that both would be very large endevours, and that we couldn't fit both in the same product cycle. We talked to customers at trade shows & to our customer council, and decided on Refactoring. We've since discussed it with customers at the PDC & elsewhere. After we talk a bit, customers usually say “I want E&C, but I agree that you made the right choice with Refactoring“.
I think we made the right choice for Whidbey. I think having well factored code has more potential to improve my productivity than having E&C. Using TDD changes the balance even further.
Still, E&C is a great feature. It's pretty clear that the future of the Visual C# product includes Edit and Continue. It's just a matter of time.
