4. November 2010 14:10
C# allows method group conversions, which simplify the invocation of delegates within your code. This is a feature that was added to C# 2.0 and when combined with the Linq extensions provided with .NET 3.5, you can drastically shorten and simplify code.
“Similar to the implicit anonymous method conversions described in §13.5, an implicit conversion exists from a method group (§14.1) to a compatible delegate type. If
D is a delegate type, and
E is an expression that is classified as a method group, then
D is compatible with
E if and only if
E contains at least one method that is applicable in its normal form (§126.96.36.199) to any argument list (§14.4.1) having types and modifiers matching the parameter types and modifiers of
Basically what the above means that the compiler is “smart” enough to infer the correct overload to call given that their is an adequate candidate method available. For example, given the following two methods:
First we can refactor the for loop using lambda expression and the Linq extensions:
Then simplify the lambda expression even further by substituting for the implicit method group conversion:
Note that the green squiggly lines are hints made by Resharper that the line of code can be refactored. If your not aware of Resharper, it’s a Visual Studio add on that turns VS from a Pinto to Ferrari! If you don’t believe me, try the free trial here. Ok, enough cool-aid and free marketing for resharper…
So, your probably thinking one of three things about now (assuming you made it this far):
- “Big fricken deal, he saved five lines of code”
- “Eh, old news. Moving on.”
- “Wow, that’s fricken awesome dude!”
Personally, I tend towards #3. I am a huge fan (obviously) of method group conversions because they reduce complexity. They simply make the code easier to read and digest. Code that is easier to read and digest is more easily maintained. Code that is easier to maintained, tends to be of higher quality and less error prone.
21. January 2010 16:14
I just spent a frustrating two hours trying to get a unit test to run via Resharper for nada. The test would start and then exit as if the it was working but instead of showing a green or red icon as expected when the test was finished, it would remain 'grayed' out. I tried the usual: delete bin folders, run solution 'clean' via VS2008, delete the code directory and do a fresh SVN checkout. I even rebooted for nothing: no red, no green all gray:
I finally noticed that I had closed the output window of VS, so I couldn't see the build results. When I opened the output window I saw this exception at the very bottom of the list:
A first chance exception of type 'System.Configuration.ConfigurationErrorsException' occurred in System.Configuration.dll
A first chance exception of type 'System.Configuration.ConfigurationErrorsException' occurred in JetBrains.ReSharper.TaskRunnerFramework.dll
The program ' JetBrains.ReSharper.TaskRunner.exe: Managed' has exited with code 0 (0x0).
What the f#*k? A configuration error was causing the Resharper taskRunner to die quietly? You have to be kdding me! Shouldn't the user be alerted if the software could not recover and had terminate? I mean, yeah it _did_ notify me, but not very explcitly - a pop up would have been nice!
Anyways, issue was found: I commented out the starting element of the ConnectionStrings section of the App.Config and when Resharper process tried to load the config it bombed. Crises averted, now back to work.
15. May 2009 22:56
I was trying to test a IEqualityComparer implementation today, when Resharper kept crashing:
I tried rebooting, rebuilding everything. I finally clicked 'Debug' and waited...nothing happened after a few minutes, so I tried re-installing Resharper to no avail. By this time I was bruning through my day, running out of time (deadlines, blah).
I clicked 'Debug' again and once again nothing happened....for awhile. I got up and ran a few 'errands' and came back an viola, I found my problem:
It was just a StackOverFlowException caused by my poor implementation of IEqualityComparer. Once I saw this I knew immediatly what was going on and how to resolve it. Of course, Resharper stopped crashing after I fixed the bug.
The big issue was why Resharper didn't handle this and just display the stacktrace as usual. It might be related to the fact that the exception was generated in TypeMock.dll, AFAIK I was not using TypeMock for this Unit test and there are no references to it in my project...weird