James Michael Hare

# re: C#/.NET Little Wonders - A Presentation

Nice slide show, except for 2 things that totally boggled my mind:

1) Using "==" to compare strings in C# "hurts readability"? Huh? IMO, it's exactly the opposite - using "Equals()" definitely hurts readability compared to "=="... Maybe if you've never used C, C++, Java, or C# before, the "==" might confuse you, but so might "!", "&&", "||", etc. Come on! Use the language like it was intended to be used!

2) Calling extension methods on null references is "not recommended"? WTF? IMO, that's actually the #1 reason for using them, 2nd to the ability to extend sealed classes. OK, perhaps in this case the language designers were thinking the other way around, but I'm sure they have no problem with using them on null references... I mean, they *did* add the "IsNull..." helper methods.

Still a nice effort, but I think those two items are actually not-so-good advice to be dishing out.

# re: C#/.NET Little Wonders - A Presentation

@Ken:

#1 lost a lot of context when just viewing the presentation since you don't get the whole talk along with it. Really, it should say maintainability instead of readability, which probably adds to the confusion. The main problem with the == operator is the fact that normally it is a reference compare unless it is overloaded for a type. And that is where the main problem lies, when you overload the == operator for a type (like string) it only works when you have references to that type. That is, if you have two objects you know are strings and pass them into a method as object, and try to compare using == you get a reference compare, not a string compare. Additionally, if you are using a generic and compare generic parameter instances using == without restricting the type using the where clause to one that defines a ==, you will get the reference == because it assumes object as the base. Does that make sense? If you have some generic SomeClass<T> that compares items using ==, even though string defines ==, SomeClass<string> will interpret == as the object reference comparison. This is why I usually argue to use .Equals because it is an override and thus you know you are always getting the correct comparison.

On #2, this is actually an industry best practice that Microsoft seems to support as well. If you use Reflector to dive into any of the LINQ methods, you'll see that they always check the "this" argument for null and throw ArgumentNullException.

There is no rule that says you "can't" do it, it's just considered a best practice.

# re: C#/.NET Little Wonders - A Presentation

Nice article -- but it's really a shame that you let "people" like Ms. "Bronze Casting" and Ms. "Health Link Exchange" and Mr. "how to become a ticket broker" put their google-bait links on your site ...

# re: C#/.NET Little Wonders - A Presentation

@Joel:

Sorry about those, I do try to review feedback and remove ones I feel are spam, I hadn't gotten around to those two yet...

# re: C#/.NET Little Wonders - A Presentation

Really interesting article. I don't know why but I hate LINQ

# re: C#/.NET Little Wonders - A Presentation

@Michael:

That's not too uncommon at first. A lot of people look at it and don't see the value or can't see past the complexity. It helps a lot of you start by just using the LINQ extension methods and then work your way into the query syntax later. Really, that's where the majority of LINQ's power lies is in the plethora of extension methods for IEnumerable that it adds.

# re: C#/.NET Little Wonders - All The Wonders In Their Glory

Hi James...
Thanks for all these information which is very helpfull.
Could you please post an article on C# collections in detail(diff between each, usage scenario for each collection).

Thanks in advance.
Balu

# re: C#/.NET Little Wonders - All The Wonders In Their Glory

@Balu: great idea I'll work on that for a post...