Events get a little overhaul in C# 4, Afterward: Effective Events

In Parts I, II, and III, I talked about the slight changes that we made to field like events, to the += and -= event accessor operators, and how this may affect you. Just so we’re all on the same page, I want to consolidate here a list of Dos and Don’ts so you know how to use these language features effectively and safely.

This is a good summary of how to use events in C# 4. Especially good to know if you like to have Warnings As Errors on (which you should).

Oh, right—sorry, I forgot. That devil will whisper, "You know, if you write this code in Visual Basic .NET, you can make the entire codebase Option Strict Off and Option Explicit Off, make the compiler shut up and you can go home early...." Hell, they've been whispering that bit of subversion since 2001. And ye Gods! The leveled cities! burned forests! cute little kitten bodies! all over the place! It's fortunate that we C# developers have kept all those Visual Basic developers on the straight-and-narrow path of true salvation static typing.

Maybe I am a static-typing fundamentalist, but you cannot say that the "dynamic" keyword in C# should be used in anything except Javascript/COM interop situations (okay, there are probably others, but it is a specialized case).

The author argues (and whines) that VB (something else I wouldn't hang my hat on) made people much more productive than C++. It did, but they had worlds of differences between them. VB.NET and C# have near zero. C# just shouldn't have dynamic/duck typing. If you want that, THEN USE ANOTHER LANGUAGE.

At least, he concedes there are different tools for different jobs. Unit testing is an area that a dynamic language excels in. I simply hate using a loosely typed anything in any kind of project that involves more than one person. Tribal styles of coding develop too easily.

Dynamic languages have their place. Just not in my C#, thank you.

Recursion can be a powerful programming technique when used wisely. Some data structures such as tree structures lend themselves far more easily to manipulation by recursive techniques. As it is also a classic Computer Science problem, it is often used in technical interviews to probe a candidate's grounding in basic programming techniques.
Whatever the reason, it is well worth brushing up one's understanding with Damon's introduction to Recursion.

Always good to look at the basics. I know I need refreshing on recursion. Especially all the types.

Lately, I've been trying out some of the new .NET 4.0 language features.  Specifically, I've been looking into ways to trivially combine late dispatch and late binding in order to build general purpose convenience objects.

The usage of dynamic feels so wrong in this example. I guess I don't see the purpose of this. To be more like javascript? No thanks.

The variations include verify no one else has the file open, if the file is in use, the file is not writable, etc ….  The answer to all of these questions is unfortunately the same.  Simply put you can’t.  The reason why is the fundamental nature of the file system prevents such predictive operations. 

Just a reminder from jaredpar. His idea is probably a good pattern to follow.

But can they be a code smell? In most cases I would say yes, for several reasons.

This blog post proposes the idea that using Extension Methods is a Code Smell. If it is, then the argument does not justify that statement.

The author gives three reasons:
"Firstly, if it is something simple, why not just implement it in the object?"
There will always be logic that has to spread across multiple objects that can only be related by interface. Inheritance should not be used just to share logical groupings of methods. Simply put properties on an interface that expose state, and then use extension methods to implement the actions that change those pieces of state. There are many good reasons not to implement logic just on the object.

"Secondly, new developers—or even experienced ones—might be confused." Sure, this is true. All developers might be confused about new ideas and methodologies. Does it mean it is bad? Of course not.

"A third scenario where I see extension methods as problematic is in the fact that they seem to be instance-based." That is the point I think. I'm not sure what actual point the author is trying to make but I think this idea is guilty of the Slippery Slope Fallacy. He actually goes to out and out to state it.

Extension methods are great because you can push functionality around just by having a class implement an interface. This does wonders for me. Of course, you could have done this before with the same Utility methods.

Ultimately, Extension methods really change nothing except for readability. I can now read right to left. The best example is using string.IsNullOrEmpty();

I no longer have to read it as string.IsNullOrEmpty(x). I just read it as x.IsNullOrEmpty() This may seem small and petty, and it is, but I think this kind of readability does wonders for communicating code to developers.

Edit: Excuse my poor initial titling, it is early :)

Warning: here be dragons. I don't think this is the right way to check for null arguments, but it was an intriguing idea.

Jon Skeet spends way too much time trying to figure out a better way to null check than the first solution he has (which is the best).

How about this: nothing can ever be null unless explicitly allowed. I've mentioned it before from another post I found. I really like it more and more.

We all hate singletons so here's another useful refactoring pattern: The Singleton Killer.

This is a step-by-step way of removing singletons from code. The solution is basically using Dependency Injection. I'm not 100% sure that DI containers should always be good, but they definitely should be considered for projects of any real size.

While exploring F#, I've grown increasingly impressed by the libraries that ship with it. One of the main purposes of the libraries is to provide underlying support for the language itself. In addition, they contain important modules and classes necessary for functional programming (e.g. immutable List and Map types). However, the most practical aspect of these libraries to me is the rich set of APIs that facilitate using the .NET Framework in a more functional way. These APIs are often directly portable to C#. Let's look at a simple example.

F# is something I need to get around to learning. Functional styles are where things should be heading. I really like C# so graduating to F# should be fun.

I’ve stated previously that reading software development books is a good way of investing in your skills and your career. But which ones should you read? And in what order should they be read? I’ve compiled a list of books that i think can truly increase your skills substantially. I’ve put them in the order in which i believe they will have the most effect, and grouped them in 3 ’stages’. I primarily have young developers who are just getting started as professional developers in mind with this list, but it should be just as useful to developers who’ve been around for a while and simply want to improve.

I've at least browsed and considered buying most of these books. After reading Clean Code, which straightened me out a good bit, I should reconsider reading the rest.