• Eric Gunnerson's Compendium

    Future language features & scenarios


    We're starting to think about the release after Whidbey in the C# compiler team.

    I know that it seems strange that we have just shipped the Whidbey beta, and we're already talking about what comes next, but we're fairly close to being “shut down” for the compiler right now. So, we're taking the “big picture“ perspective.

    Since we're in this mode, now's the time to suggest things that we should add to the language and/or scenarios where you think the language falls short.

    An ideal comment would be something like:

    I'd like to be able to support mixin-style programming in C#

    If it isn't obvious what you're suggesting, please provide a link.

    It would also be good to suggest through code - something like:

    I currently am forced to write code like

    <ugly code here>

    and it's really ugly.

    I won't be able to respond to all comments nor will we implement all of them (or perhaps any of them), but we will consider all of them.



  • Eric Gunnerson's Compendium

    Nullable types in C#


    Nullable Types in C#

    One of the "late breaking" features in C# 2.0 is what is known as "Nullable Types". The details can be found in the C# 2.0 language spec.

    Nullable types address the scenario where you want to be able to have a primitive type with a null (or unknown) value. This is common in database scenarios, but is also useful in other situations.

    In the past, there were several ways of doing this:

    • A boxed value type. This is not strongly-typed at compile-time, and involves doing a heap allocation for every type.
    • A class wrapper for the value type. This is strongly-typed, but still involves a heap allocation, and the you have to write the wrapper.
    • A struct wrapper that supports the concept of nullability. This is a good solution, but you have to write it yourself.

    To make this easier, in VS 2005, we're introducing a new type named "Nullable", that looks something like this (it's actually more complex than this, but I want to keep the example simple):

    struct Nullable<T>
        public bool HasValue;
        public T Value;

    You can use this struct directly, but we've also added some shortcut syntax to make the resulting code much cleaner. The first is the introduction of a new syntax for declaring a nullable type. Rather than typing:

    Nullable<int> x = new Nullable<int>(125);

    I can write:

    int? x = 125;

    which is much simpler. Similarly, rather than needed to write a null test as:

    if (x.HasValue) {...}

    you can use a familiar comparison to null:

    if (x != null) {...}

    Finally, we have support to make writing expressions easier. If I wanted to add two nullable ints together and preserve null values, if I didn't have language support, I would need to write:

    Nullable<int> x = new Nullable<int>(125);
    Nullable<int> y = new Nullable<int>(33);
    Nullable<int> z =  (x.HasValue && y.HasValue) ? 
    new Nullable<int>(x.Value + y.Value) : Nullable<int>.NullValue;

    At least I think that's what I'd have to write - it's complex enough that I'm not sure this code works. This is ugly enough that it makes using Nullable without compiler support a whole lot of work. With the compiler support, you write:

    int? x = 125;
    int? y = 33;
    int? z = x + y;
  • Eric Gunnerson's Compendium



    Today I spent a few hours playing Halo2 - after waiting 90 minutes with 1000 of my closest friends outside the Microsoft company store.

    The campaign seems to be pretty good, but it has the usual problem with FPS campaigns, where it needs to strike a balance between giving you freedom of action and keeping you to a predefined path. Overall, it's been pretty good, but right now I'm stucking in a room with a floating guy (more would likely be a spoiler). If you know how to get out of that room, please drop me a line.

    I'll be on XBox live on and off. My gamertag is CeeEff.

  • Eric Gunnerson's Compendium

    How do you look for code?


    Another question, this time from one of the other PMs on the team:

    The C# team is trying to understand how you look for code when stuck or trying to learn some new technology. Currently the solution we provide is in the documentation – you can find among other things -

    • Walkthroughs on the product
    • Documentation for each method
    • How to articles that target specific tasks
    • Code snippets
    • Working pieces of code that we ship in the product that do a specific task.

    How do you try to find code for a task that you don’t know how to write? Is the Help content in VS organized well and is it adequate? What would you change to help people ramp up on new code, tasks, or the capabilities of the tool faster? What annoys you about the samples we provide today?


  • Eric Gunnerson's Compendium

    Question: Renaming windows forms?


    I'm working on resolving an issue, and the way that we decide depends upon the prevalence of a specific scenario. I'd like to know your opinion on the following Windows Forms scenario.

    How often do you rename the form class without renaming the file that holds the form class? ie how often do you change "class EmployeeForm" to "class AddressForm" without also renaming the form file?



  • Eric Gunnerson's Compendium

    Be a language designer...


    I started writing a normal blog post - well, as normal as any blog post of mine ever is - and then I decided to let you do the hard work. So here's the situation.

    You're part of the C# language design team thinking about the next version of C# (ie the version after VS 2005). You get the following email:

    When I'm writing code, I often come across a situation where my code throws an exception because another component called with a null parameter. I'd like a way to prevent that from happening.

    What are the pros and cons of such a feature? What are the ramifications of adding it to the language? What would have to change? What is your recommendation? Exactly what would such a feature look like?

  • Eric Gunnerson's Compendium

    The solution explorer and windows forms


    I have a design question for you. Yes, I don't own the project system anymore, but I started this particular issue, and I want to follow up on it:

    In VS 2002, whenever you double-click on a form file in solution explorer, the project system always opens the form designer on that file.

    We are considering modifying the behavior in Whidbey so that the project system will track the most-recently-viewed state for the file. If you had most recently looked at the code view, double-clicking would take you to the code view. If you had most recently looked at the design view, double-clicking would take you to the design view. This state would not be persisted across closing and reopening the project.

    What do you think? Should we stick with the current behavior, or should we change to the new behavior? And why?

  • Eric Gunnerson's Compendium

    Music Recommendations


    I'm spending a lot more time listening to music in my new job, and I'd like to expand my collection.

    That's where you come in.

    I need some recommendations. For reference, here are a few group I listen to:


    • Rush
    • Green Day
    • Third Eye Blind
    • The aforementioned Queensryche
    • The Police
    • The Cars
    • The Who

    Jazz (ish):

    • Rippingtons
    • Lee Ritenour
    • Bruce Hornsby

    Industrial/Whatever (I don't keep up on the labels...)

    • BT
    • Orbital
    • Robert Miles
    • Stereo MC's
    • The Crystal Method


  • Eric Gunnerson's Compendium

    Continue "What's wrong with this code?"


    I'd like an opinion on whether you are find the "what's wrong with this code?" items useful at all, and whether you think I should continue to do them.

    Also, if you have any ideas for how to make them better - ideas that wouldn't take a lot of time - please let me know.

  • Eric Gunnerson's Compendium

    C# vs C++


    [Update: Changed a misplaced "C#" to a "C++" in the tools section. Thanks, Nick]

    At the class a took a while back, the instructor asked me to talk a little bit about the benefits of C++ vs the benefits of C#, since I had worked in C++, then in C#, and now in C++ again.

    I talked for about 5 minutes on why C# was better, in the following themes. Note that I'm speaking about the whole programming environment, not just the language.

    Automatic memory management

    There are several facets of this. When I read or write C++ code,  I keep part of my attention on the algorithmic aspects of the code, and another part on the memory aspects of the code. In C#, I usually don't have to worry about the memory aspects. Further, in C++ I need to figure out who owns objects and who cleans them up, and also figure out how to clean up in the presence of error checking.


    Without a lot of dedication, using return codes is a bug farm waiting to happen. In the C++ world, some functions return HRESULT, some return a bool, some return another set of status code, and some return a number and use an out-of-range value as an error indicator. Oh, and some are void. You not only have to write the correct code there, you have to successfully convert back and forth between the various kinds of error handling.

    You also lose the opportunity to write more functional code. I end up writing something like:

    CString name;

    instead of writing:

    string name = employee.FetchName();

    And, of course, exceptions are fail-safe in that you get error reporting without doing anything, rather than having to do everything right to get error reporting.

    Coherent libraries

    The C++ code I'm writing uses at least 6 different libraries, all of which were written by different groups and have different philosophies in how you use them, how they're organized, how you handle errors, etc. Some are C libraries, some are C++ libraries that are pretty simple, some are C++ libraries that make heavy use of templates and/or other C++ features. They have various levels of docs, all the way from MSDN docs through "read the source" docs to "a single somewhat-outdated word doc".

    I've said in the past that the biggest improvement in productivity with .NET comes from the coherent library structure. Sure, it doesn't cover everything in Win32, but for the stuff it does cover, it's often much much easier to use than the C++ alternative.

    Compilation Model

    C++ inherited the C compilation model, which was designed in a day when machine constraints were a whole lot tighter, and in those days, it made sense.

    For today, however, separate compilation of files, separate header and source files, and linking slow things down quite a bit. The project that I'm working on now takes somewhere on the order of a minute to do a full build and link (that's to build both the output and my unit tests, which requires a redundant link). An analogous amount of C# code would take less than 5 seconds. Now, I can do an incremental make, but the dependency tracking on the build system I use isn't perfect, and this will sometimes get you into a bad state.


    Reflection is a great feature, and enables doing a ton of things that are pretty hard to do in the C++ world. I've been using Source Insight recently, and while it's a pretty good IDE, it isn't able to fully parse templates, which means you don't get full autocompletion in that case.

    Code == Component

    In C#, you get a component automatically. In C++, you may have extra work to do - either with .IDL files or with setting up exports.

    Language Complexity

    C++ templates are really powerful. They can also be really, really obtuse, and I've seen a lot of those obtuse usages over the years. Additionally, things like full operator overloading are great if you want a smart pointer, but are often abused.

    And don't get me started on #define.

    The alternate view

    So, if what I say above is true, the conclusion looks pretty clear - use C#. Not really much surprise considering who came up with the list.

    But there are things that C++ has going for it, and it really depends on the kind of code you're writing which language is a better choice. In broad strokes (and in my opinion, of course), if you're doing user applications (either rich client or web), choosing C# is a no-brainer. When you start getting towards lower-level things like services or apps with lots of interop, the decision is less clear.

    So, what do I think you get in C++? A few things spring to mind.

    Absolute control over your memory

    I think you actually need this level of control much less than you may think you need it, but there are times when you do need it.

    Quick boot time

    Spinning up the CLR takes extra time, and it's likely to alway take extra time  (unless it's already spun up in some other manner). You don't pay this penalty in the C++ world.

    Smaller memory footprint

    Since you aren't paying for the CLR infrastructure, you don't pay for memory footprint.

    Fewer install dependencies

    You can just install and go, and your users don't have to install the proper version of the CLR.


    So, that's pretty much what I said in the class. What did I miss?

  • Eric Gunnerson's Compendium

    Eric should write a blog post on...


    I've been tracking topics I wanted to cover in various methods (excel spreadsheets, Post-It (tm) notes, “post-it compatible” notes, writing on my hand, and graffiti in my office).

    It's been hard to keep all of those straight, so I'd like to centralize them in a blog post. If you have a question that you'd like me to answer, please add a comment to this post with your question.

    I'll put a link on the top-level web page of my blog, so that you can easily get to it. I'll try to put some of my own ideas there as well.


  • Eric Gunnerson's Compendium

    How do you organize .NET?


    Shaykat and I have been having a discussion about how we organize information that we present to customers. Specifically, we're trying to figure out how to present “What's new/what's changed” information. There are two options we've been considering.

    The first option considers the language attribute to be the high-order bit. It would look something like:

    What's new in C#
    * C# Language
    * C# IDE
    * Debugger
    * XML
    * Data
    * ASP.NET
    * Windows Forms
    * Smart Client
    * CLR
    * BCL

    What's new in VB
    * VB Language
    * VB IDE
    * Debugger
    * XML
    * Data
    * ASP.NET
    * Windows Forms
    * Smart Client
    * CLR
    * BCL

    The second option is to consider language one of the organizational attributes, but not the only attribute. It would look something like:

    What's new in C#
    * C# Language
    * C# IDE

    What's new in VB
    * VB Language
    * VB IDE

    Application Types
    * What's new in ASP.NET
    * What's new in Windows Forms
    * What's new in Smart Client applications

    * What's new in the CLR
    * What's new in the BCL
    * What's new in Data
    * What's new in XML

    Which one of these organizations do you prefer? Please add a comment with “Language” if you prefer the first one, and “Attribute” if you prefer the second one. Or, if you think there's another organization that's better, feel free to explain.



  • Eric Gunnerson's Compendium

    Miss manners will help you now...

    Etiquette Hell
  • Eric Gunnerson's Compendium

    Want to review my new book?


    I got a request from my publisher for reviewers for the third edition of my book. You would get a copy of the book, read it (that part's optional), and then write a review of it on Amazon.

    So, if you'd like to participate, leave a comment with the reason I should choose you to be a reviewer, and I'll choose the 5 best in a week or so.

    [Update: I probably should have mentioned that I think this is limited to people with US addresses. ]

  • Eric Gunnerson's Compendium

    "Holiday Lights" or "Christmas Lights"


    In response to my Holiday Lights post, "a guy" wrote:

    They're Christmas lights, dude. Jews don't string up lights. So while it's properly a "holiday party" at your office, and you wish people "happy holidays" (not knowing their religion), you just don't put up holiday lights. No such thing.

    I was going to just let this go, but I decided I'd comment on it.

    The celebration of Christmas as a Christian holiday is as an overlay over existing celebration that occured on December 25th. The Egyptians celebrated the birthday of Ra, the sun god, on that day, as it was just after the winter solstice. Many other societies have also had celebrations on the solstice, and December 25th only became a christian holiday by the declaration of pope Julias I in the 4th century.

    So, as somebody who isn't religious, I'm going to stick with the term "Holiday lights". I think there's a good reason to celebrate the days getting longer (*beyond* the fact that it's the start of the good skiing, which is a reason of its own) even if you don't believe there's a deity involved.

    I may switch to "Solstice lights", but I think that could be more bother than it's worth.

  • Eric Gunnerson's Compendium

    No longer Large, and rarely in charge...


    For those of you who have never met me, I'm approximately 6'2” tall, and currently weigh about 168 pounds. For all of my (reasonably) adult life, I've been a “Large”. If I needed a T-shirt, or a coat, or a sweatshirt, I was always a Large.

    My consistent largeness provided comfort as I navigated the often turbulent waters of life.

    But recently, things have changed. America has - and I'm sure I'm not telling you anything new, unless you've been living in a cave for the past 10 years (presumably a cave with a nice 100 MBit network, a cable modem, and a kickin' gaming system), you've probably noticed that America has been getting fatter. Not the country, which at my last measurement, was just a bit under 1000 leagues wide, but the people.

    For a while, this was no issue, but clothing manufacturers have started to adjust their sizes upwards, which means that Large isn't the Large that I have grown to love. But, of couse, all of them haven't done it, so now I sometimes end up with a large, and sometimes with a medium. Not that bad if you can try them on ahead of time, but for TechEd I got two Large shirts - you have to order large because if medium is too small, you're SOL - and I swim in them a bit. I guess I could wear 10 or 12 T shirts underneath to fill it out a bit, but that hardly seems practical.


  • Eric Gunnerson's Compendium

    To m_ or no to m_, that is the question...


    I apologize for shocking your system by posting more than once a month - there are reasons for that, but I unfortunately can't get into them right now - but Keith added an interesting comment to my last post. He said:

    Side Note: a bit disturbing you're using C++ naming conventions in C# though? :)  No doubting your a ninja coder and I love your stuff, but seriously, bringing the m_ prefixing into C# is a bit of a "cant teach an old dog new tricks" thing.  

    This is pretty close to a "religious question", but since it's my blog, I'm always right (as codified in the "decree on Gunnerson infallibility of 1997"), so I'll take it on.

    When I first started writing code, a lot of our samples were written without any way of indicating whether something was a field or not, and I wrote a considerable amount of code using that idiom. What I found was that when I went back and looked at my code later, I had to scroll around to find out where each variable came from, and that made understanding the code harder.

    I toyed for a while with using just and underscore "_name", but I didn't like that. A single underline is a bit hard to pick up visually, and it seemed like I was inventing a different expression just to be different. So, I switched back to "m_", and I must say that I'm happy with the choice. The only place I don't like it is with events or other public fields, which are then named differently, but I'm willing to deal with that.

    The only other place I use prefixes is on pointers, where I just use "p". Unsafe code is rare enough that I want to have an indicator of what's going on.

    [Update: Another reason to use m_ is to make it easier to find your variable names in intellisense when you're working with controls, since there are roughly 4000 members in the average control class. I've also been using "c_" in the names of controls for the same reason]

    So, what do you think, keeping in mind that if you disagree, you're wrong...

  • Eric Gunnerson's Compendium

    zero or one based collection?


    moo asks:

    Zero based collections or 1 based?

    Since programming languages are a bridge between the human concept of a solution and we naturally think the first element is in position 1, why was this not so on the actual language? Why are we made to think like a machine when infact we are not? The infamous "Off by one bug" is there because of the inherant design. So popular its even got a name yet we do nothing to prevent this happening at the language level, as for those who say its easier for the computer, thats why we have smart compilers. Im not a compiler dammit.


    One of my hobbies is rewriting lines in TV and films, and I am therefore impelled to comment that moo's last line should be:

    I'm a programmer, not a compiler, Jim

    To cover this subject, I'm going to have to set the way-back-machine for the 1980s or earlier, back when real men wrote in assembly and our bytes only had 7 bits. (aside - How many of you - and be honest here - have ever heard of machines where the word size wasn't a multiple of 8? They really did exist).

    Anyway, in those ancient times, processors were fairly glacial in their arithmetic speed, though much faster than the early calculators. Saving cycles was very important, so when arrays were first considered, the implementers looked at the code they wrote:


    translates to

    address = base_address + (x - 1) * sizeof(x)

    They actually didn't write it that way because they didn't have multiplication in those days, but that gives you the idea. Then somebody noticed that if your array starts with zero, you could write it as:

    address = base_address + x * sizeof(x)

    Thereby saving you a single decrement operation, which was important in those day.

    Therefore early programmers got used to zero-based arrays, and the path was set, and it has stayed that way for many years for the majority of languages.

    But why? Isn't it simple enough to change?

    It's obviously trivially easy to change, and Moore's law has made the efficiency inconsequential in the majority of scenarios. The issue isn't around technological limitations, but rather human ones.

    Understanding how zero-based indexing works is the secret handshake of the programming world. We all started not knowing the secret handshake, but over time we learned and even began to like the secret handshake, and now we don't know any other way to shake hands.

    We're not going to try to change our brain wiring just because some young whippersnapper is having trouble remembering that the first index is zero.

    Or, to put it another way, developers have a huge investment in hardwired things like this, and changing them will not make your customer happy.

    [Update: Jack wrote:

    Why cant we either have 1 based or user definable array bounds?

    The CLR does support this kind of construct (I had a hard time not using the term “travesty“ here...), but there aren't, to my knowledge, any languages that have built-in syntax to do that.

    Which is a very good thing. If you go down that route, rather than having to remember a single rule (C# arrays are zero-based), you have to remember that every array could be either zero-based, so all your loops become:

    for (int index = arr.GetLowerBound(); index <= arr.GetUpperBound(); index++)

    If you get this wrong, you get code that works fine for your test cases, but breaks for the people who like 3-based arrays.

    Yuck. Many times, “make it an option“ is the worst choice.



    Ferris adds:

    Why bother creating a new language if you are still hugging your legacy pillow at night. Waste of time.

    One of our main goals was to create a language that was comfortable to C/C++ programmers. We could have taken a different tack, and designed a new language from scratch, and perhaps done some new and exciting things.

    But if you look at all the languages out there, you'll find that having a comfortable syntax is well correlated with language success. Even if you've never written C# code before, if you have experience with a C-style language, you'll be able to read C# code.


    You can find another discussion of this issue here.

  • Eric Gunnerson's Compendium

    C# - What's wrong with this code? - #1


    Many months ago, I did a TechEd talk entitled "What's wrong with this code?". I've decided to re-target those snippets into blog posts. If you were at the talk, this may be boring, though I'll try to add a little anecdotal information in my answers.

    Here's the plan:

    1. I post the snippet
    2. You comment on what's wrong with it
    3. I post my answer, and any comments that I like
    4. Repeat until I run out of snippetts.

    Here's the snippet:

    switch (s) {
       case "a":
          try {
          catch (Exception e) {
             throw e;
       case "b":
          try {
          catch (Exception e) {
             throw e;
    What's wrong with this code?
  • Eric Gunnerson's Compendium

    Field names...


    There are three common choices for field name conventions in C# code:

    1. No prefix ("string name;")
    2. Underscore ("string _name;")
    3. MFC-style ("string m_name;")

    I label the third MFC-style because that's where I first encountered it.

    In the past, I haven't expressed a strong opinion for any of these, and I've written some C# code that used style #1 and some that used style #3. I recent experience, however, has pushed me in one direction.

    On Monday, I did two separate code reviews. One was for a C++ class that one of my teammates has written (we do code reviews on all of our code), and the second was on a C# sample written by a C# PM.

    When I was reading the C# code, it was hard to follow in places, and it took me a while to realize that what I was missing being able to know instantly whether an identifier was a field, or whether it was a parameter or local.

    So put me firmly in the MFC-style camp for naming. #2 is also a reasonable choice, but I think it feels to much like a compiler-defined construct for my taste. Thankfully, I'll have refactoring when I need to revisit my old C# code...


  • Eric Gunnerson's Compendium

    Super bowl officials...


    I'd like an unbiased opinion on this one. And I'm only going to make one post on this, so bear with me.

    I think the Steelers played a pretty good game - and managed to do some nice things - converting both long runs and a nice trick play for touchdowns. The Seahawks did some good things, but did a poor job managing the clock at the end of both halves.

    But the officiating was, well, just weird.

    Darrell Jackson catches the ball in the endzone, the ref doesn't signal anything, the Steeler DB protests, and the ref throws a flag. Clearly no interference. Seahawks settle for a field goal.

    Roethlisberger's touchdown was pretty darn close, and I couldn't really tell if he scored, but it looked like he didn't. I think this is largely irrelevant as my guess is that they would have gone for it on 4th and scored, but the Seahawks have stopped a few of those this year, so it wouldn't have been as clear.

    The killer, however, was the holding call on the Hasselbeck throw to Jeremy Stevens. It was pretty clearly not holding, and this was the big momentum change of the game.

    Then, on the ensuing interception, Hasselbeck gets called for a low block, which is just wrong.

    So, what do you think?

  • Eric Gunnerson's Compendium

    What's Wrong with this code - #4


    Here's another one for you. This segment of code gets the list of all responses to be sent and sends them.

    public void TransmitResponse(ArrayList responses, 
                                 StreamWriter streamWriter)
       foreach (DataResponse response in responses)
          NetworkResponse networkResponse = response.GetNetwork();
       GC.Collect();      // clean up temporary objects

    Three questions:

    1) What's wrong with this code?
    B) Why?
    III) What should you do instead?

  • Eric Gunnerson's Compendium

    Life simplification redux...


    Back in June, I wrote a post about wanting to simplify my life, and to enjoy life more.

    I've made progress in some areas, not so much in other areas. Last summer I ended up pretty burned out, and I feel like I'm just starting to get caught up on a lot of things. So, here's a quick report on how I did, and what I'm planning on doing next.

    Jay has also been on a similar quest.

    So, one the plus side:

    • Get a job that's exciting and places fewer demands on my family time. Done.
    • Get the final inspection done on our ski place, and stop paying King County $500 each year to renew the permit.
    • Sell the motorcycles. Done.
    • Cancel some magazines. Done.

    Work in progress:

    • Get my investments in order. We have a mismash of different accounts - multiple IRAs, CDs, and various investment accounts. I've opened a Scottrade account that has most of my stock investments, but I still have too much money in underperforming accounts. I also own some MS ESPP stock that I need to sell. On the other hand, I've done fairly well in the stocks that I've purchased.
    • Be more "there" for my family. I've been better here - I spend much less time on email, but my Halo2 time has been a little too much. I need to limit this to times when I really want to play, rather than just doing it because I can't find anything else to do. Of course, I do have a level 10 small team ranking to show for it.
    • Cook more. Not "heat up", but "cook". I really haven't done much of this, and have settled for making more pedestrian meals. I need to find a cuisine to work on, or a new type of dish. Suggestions welcome.
    • Remodelling. Well, this is probably going to be an ongoing project for a long time. I've gotten a few things done and a few others planned, but I just need to get off my butt and get them started.

    Another project is "add storage to the house". It's somewhat paradoxical, but I've found that having good storage is a good forcing function to get you to go through things and get rid of stuff that you don't need any more. If a room is always cluttered even if you cleaned things up, it's easy for things to get out of shape.

    I now have four 36 x 24 x 80" Ikea pantry cabinets in the garage, and three more that will go in our laundry room as soon as we get a floor down. They hold a considerable amount of stuff, and my garage is moving towards clean and organized.

    What have you done to make your life simpler and more organized?

  • Eric Gunnerson's Compendium

    Edit and Continue in Whidbey...


    Soma has just announced that C# will support Edit and Continue in Whidbey.

    Waaay back when we first planned Whidbey, one of the questions we asked was "is refactoring or edit and continue more important"? We knew that our users wanted both, but we didn't have schedule time to do them.

    The answers we got back were along the lines of "refactoring, but we'd also like E&C as well".

    At the time, it was an either/or choice, and we did refactoring. After talking with customers at the last PDC, it was apparent that the desire for E&C was pretty high. We explored if there was any way to do E&C in Whidbey, and came up with a way to make it happen. And now, thanks to the hard work of many on the C# team (excluding me, who didn't really do much of anything), the feature will be available in the next community preview.

    So why didn't we tell you earlier? Why did Eric lie to you when you came up to him at TechEd and asked about E&C?

    Well, the fact is, it was a very near thing. If a few technical details or schedule points had come out a bit different, it wouldn't have made it into the product. We decided to delay announcing until things were firm rather than risk having to de-announce a feature.

  • Eric Gunnerson's Compendium

    What's wrong with this code?


    TechEd is rapidly approaching, and I'm signed up to do a “C# Best Practices” kind of talk.

    Rather bore my audience by presenting my views on implementing IDisposable, I'm going to take the “What's wrong with this code?” approach. My goal is to present code examples that show code that's doing something wrong - be it something prohibited by the language, something that's ill-advised, or something with bad performance - and then let the attendees try to figure out what's wrong with the code.

    I have a list of 10 or 15 items already, but I'd like to steal leverage your experience in this area. If you have a “poor practice”, please post the code, and then leave some blank space before you explain why it's bad, so that others can try to figure them out on their own. I'm especially interested in code that you (or somebody else) wrote where you didn't understand initially what the problem was. In other words, the subtle ones.

    Here's one of my favorites. What's wrong with this code?

    public class Processor
        DataStore dataStore;

        public Processor(DataStore dataStore)
            dataStore = dataStore;

        public void Process(DiscountStructure discStruct)
            catch (Exception e)
                 if (e.InnerException.GetType() == typeof(ProcessFailedException))
                     throw new InvalidActionException(e.InnerException);

Page 1 of 46 (1,150 items) 12345»