That's quicksort. :) Actually, I guess it depends on whether you're using IEnumerable or IQueryable...

Let me attempt to rephrase. I am not saying that choosing a complex solution over a simple solution to the same problem is legitimate. What I am trying (perhaps failing) to state is that choosing either a complex or a simple solution to ANY problem without first truly understanding the problem at hand is uninformed. For example, the quicksort or mergesort algorithm is very complicated when compared to the bubblesort algorithm. You can elegantly express a bubblesort in most programming languages in three or four lines of code. However, for the vast majority of sorting problems, it is better to go with the more complex quicksort or mergesort versus the simpler bubblesort.

I am staunchly against the premise that simplicity is better. I am also staunchly against the premise that complexity is better. If you don't take the problem at hand into account, choosing either simplicity or complexity is an uninformed decision.

Amen to that.

"But that’s not the point—you’re not here to write code; you’re here to ship products."

I currently work at a job where, by nature of the very tight deadlines, I am REQUIRED to be a duct-tape programmer. We pull crazy miracles out of our duct-taped code to get stuff shipped and out the door. Yes, I get the job done, but for the scope of many projects I work on, I pay a huge cost later in trying to maintain the damn thing. The part of his article that scares me is that he does not take the scope of project into consideration at all. Duct-tape coding is not a good or bad trait in and of itself, but there is a time and place for it. As you mention, the same goes for design patterns. You don't (or shouldn't) use them just to say you did or to appear smart, but when applied appropriately, they can cleanly solve real problems that you'd be otherwise scratching your head about. On larger projects, when requirements change (and they WILL change), you're left trying to cut through all the wadded up duct tape you left behind, wishing you'd spent a little less time with duct tape and a little more time actually thinking things through.

? You seem reasonably intelligent to me... or was it tongue-in-cheek?

FxCop is absolutely a static code analyzer. Perhaps you are thinking of StyleCop.

You will be happier in the long run if you do Select New With {c, cv}

If this is a full-blown SQL Server box, you probably want to look at using SSIS to do this.

Is this through WPF or Windows Forms? Also, are you building a new tab control more for fun, or to meet a need that the built-in tab control didn't meet?

Nothing is built in to .NET as far as I know. There are several third-party components that will talk to email servers, though. If you want to talk to an email program, I think COM/MAPI is still it.

Luc summed it up well, but I just wanted to add one other non-obvious difference. With value = null; Convert.ToInt32(value) returns 0 int.Parse(value.ToString()) throws NullReferenceException. int.Parse(value) throws ArgumentNullException. (if value is String)

My pleasure! :) Happy I could help.

Augh... that's terrible. :)

Thanks... I did write that way under Dictionary way already, though. :)

Yes, it should work with enums. Again, though, it really depends a lot on what you're trying to do, so it's hard to recommend one approach over another... but here's a sample of some different techniques. Each have their strengths and weaknesses, depending on your situation. Assuming an enum like:

enum MyEnum { Foo, Bar, Baz }

switch way:

bool method(MyEnum val)
{
switch (val)
{
case MyEnum.Foo:
Console.WriteLine("Some");
Console.WriteLine("big");
Console.WriteLine("case");
Console.WriteLine("statement");
Console.WriteLine("that");
Console.WriteLine("Foo");
Console.WriteLine("does");
return true;
case MyEnum.Bar:
throw new Exception("Bar!");
case MyEnum.Baz:
Console.Beep();
Console.WriteLine("Beep.");
return false;
default:
throw new ArgumentOutOfRangeException("val");
}
}

Refactor to methods way:

bool method(MyEnum val)
{
switch (val)
{
case MyEnum.Foo:
return FooMethod();
case MyEnum.Bar:
return BarMethod();
case MyEnum.Baz:
return BazMethod();
default:
throw new ArgumentOutOfRangeException("val");
}
}

bool FooMethod()
{
Console.WriteLine("Some");
Console.WriteLine("big");
Console.WriteLine("case");
Console.WriteLine("statement");
Console.WriteLine("that");
Console.WriteLine("Foo");
Console.WriteLine("does");
return true;
}

bool BarMethod()
{
throw new Exception("Bar!");
}

bool BazMethod()
{
Console.Beep();
Console.WriteLine("Beep.");
return false;
}

Dictionary way (.Invoke() is just for clarity):

delegate bool BoolFunc();
readonly Dictionary<MyEnum, BoolFunc> methods;

MyClassConstructor()
{
methods = new Dictionary<MyEnum, BoolFunc>();
methods.Add(MyEnum.Foo, FooMethod);
methods.Add(MyEnum.Bar, BarMethod);
methods.Add(MyEnum.Baz, BazMethod);
}

bool method(MyEnum val)
{
BoolFunc funcToCall;

if (!methods.TryGetValue(val, out funcToCall))
	throw new ArgumentOutOfRangeException("val");

return funcToCall.Invoke();

}

bool FooMethod()
{
Console.WriteLine("Some");
Console.WriteLine("big");
Console.WriteLine("case");
Console.WriteLine("statement");
Console.WriteLine("that");
Console.WriteLine("Foo");
Console.WriteLine("does");
return true;
}

bool BarMethod()
{
throw new Exception("Bar!");
}

bool BazMethod()
{
Console.Beep();
Console.WriteLine("Beep.");
return false;
}

Subclass/override way (the enum actually goes away here):

b

You have a few options... it depends on the situation, really. One possibility is to take the bodies of the case statements and make methods out of them. Another is to create a dictionary of key to delegate, and do a dictionary lookup/invoke in place of a switch. Another is to look for an object-oriented way where you differentiate behavior by overriding an abstract/virtual method, in place of a switch statement somewhere. All depends, though. :)

No, the contract is not broken for IEEE math. ceq on float32/float64 obeys the rules. (double.NaN != double.NaN and float.NaN != float.NaN)

Part of having a unified type system means that there is no difference between float64-the-primitive and System.Double-the-object - they must be treated as one and the same. However, now you have a contradiction. The definition of equality for floating point numbers is fundamentally incompatible with the contract for equality of objects in .NET. Floating point requires that NaN must not equal NaN. System.Object requires that a.Equals(a) returns true. If you make a special exception for the a.Equals(a) rule for doubles and floats, you have now broken the contract of equality for objects and thus broken polymorphism. One can no longer write code under the assumption that a.Equals(a) always holds true.