Tuesday, 10 June 2008

The Resharper cult members already know this, but for those who haven't joined yet, version 4.0 released today with VS 2008 support -- huzzah,  huzzah.  No longer able to resist the chanting and promises of eternal coolness I donned my robe and installed my free copy.

I clearly should have joined sooner.  Resharper has already changed my life.  First it pointed that I had redundant overrides  in the control I was working on, which I had really meant to delete.

Then it reminded me about the new implicit type declaration keyword var, so this...

XmlDocument SomeDoc = new XmlDocument();

becomes...

var SomeDoc = new XmlDocument();

Granted, that's not too exciting, but if your type declaration is something like...

Dictionary<SomeStrangeType,ANamespace.AnotherLongType> SomeDictionary = new Dictionary<SomeStrangeType,ANamespace.AnotherLongType>();

with var it becomes...

var SomeDictionary = new Dictionary<SomeStrangeType,ANamespace.AnotherLongType>();

Then Resharper pointed out something I didn't realize was available in C#, the object intializer?? VB.NET has long had something similar with the With statement (now with object initializer goodness too).  What's nice about this is that it saves repeating the instance name in front of the properties.  So this...

var MenuBinding = new MenuItemBinding();
MenuBinding.DataMember = MenuItemElementName;
MenuBinding.TextField = DisplayTextAttribute;
MenuBinding.NavigateUrlField = NavigationUrlAttribute;
MenuBinding.Depth = Depth;

becomes...

var MenuBinding = new MenuItemBinding
  {
     DataMember = MenuItemElementName,
     TextField = DisplayTextAttribute,
     NavigateUrlField = NavigationUrlAttribute,
     Depth = Depth
  };

I was staring at this new construct when I realized that -- it shouldn't work. The project I was working on was a Framework 2.0 project and these things were in 3.0 syntax.  But the darn thing compiles and works.  Not even a single warning.  WTF?  It turns out that since 3.0 and 3.5 are based on 2.0, these are simply compiler tricks -- there is nothing fundamentally different about the types.  Here's a blog post that explores in more detail what is happening under the covers.

Not bad for 15 minutes of tooling around.  Guess I am an official member. Where's the Koolaid?

.NET | 2.0 | 3.0 | 3.5 | Resharper
Tuesday, 10 June 2008 22:24:01 (Eastern Standard Time, UTC-05:00)   #     Comments [0]  | 
Thursday, 05 June 2008

Every month or so, someone posts a question on one of the .NET forums I frequent asking if such and such will work, or if you can do so and so. The post will detail the background of the issue, including theoretical approaches, possible drawbacks, imaginary contingencies and tangential concepts.  Invariably the poster wants to know the "proper way" to code something, and yet 6 paragraphs later hasn't shown what he or she has already attempted.

Why?

Because the poster hasn't written any code yet

Philosophical development discussions can be fun. Reviewing fundamental design issues, or exploring the possibilities of a new technology or entering a new problem space beg for "what if" questions. It's good to have an idea where to go, a vague notion how to get there and to find out how others attempted the journey.   Those are fun questions to answer.

Another excellent time to ask "what if" questions is when facing an irrevocable upgrade or configuration change.  When a wrong step can wreak havoc it wise to ask for advice. That's what a forum is for -- to get pointed in the right direction or pushed back on course or to be told to hurry back to shore.

No, what makes a coding "what if" question a total waste of time and bandwidth is when it asks how to write a relatively small amount of code. The post itself is longer than the most convoluted possible solution. To put it programmatically...

if(Post.Length > Code_Needed_To_See_If_It_Works.Length)
    WasteOfTimeAndBandwidth();

In other words, if the poster had actually tried to code one of the carefully penned theoretical approaches, he or she would have ended up typing a lot less and would have discovered the solution without a trip to forum land. 

Some examples (and I wish I were making these up):

  • Is it possible to set SomeObject.SomeProperty = SomeValue?
  • Can I put this control inside this other control?
  • How long will SomeObject.SomeMethod() take to run?

Programming is a wonderfully empirical undertaking. With IDEs (Integrated Development Environments such as Visual Studio) it is easy to create code and test it.  At the level of of a function or even a web page or windows form, there is no need for thought experiments or theoretical ponderings -- the code either does what it is supposed to or it doesn't.  There is no need to write about it -- just write it.  If it doesn't work, then you can post a question that is based on something real.

Unless you are doing something silly like working on a production system, the cost for trying something out is minimal.  In the worst cases, bad code throws an error or just doesn't work.  Things don't explode, no one dies.  With source code/version control (which everyone should get into the habit of using), it is trivial to roll back to a previous working version. 

So please, for your sake and Pete's, try it first.  See what happens.  You'll save some time and might be pleasantly surprised.

Thursday, 05 June 2008 19:59:09 (Eastern Standard Time, UTC-05:00)   #     Comments [0]  | 

Theme design by Dean Fiala

Pick a theme: