Adam Hathcock’s Life in Software

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.

Added unexpected feature: Streams for single and multipart archives. They must be seekable however. Maybe non-seekable streams soon when someone asks.

Another minor bugfix. Ran into this myself when I was trying to convert CBR files to PDFs. Spent so many hours chasing this down.

Until recently your only choice for developing applications for Apple’s iPhone was to jump into the Apple development ecosystem. This means being willing to write Objective-C code in the XCode IDE. For many developers, learning Objective-C was seen as a huge barrier-to-entry. This is especially true for many .NET developers whom have never had to worry about memory management, pointers, and other C language responsibilities that they are unfamiliar with.

Very long and good. I've only read the first bits and skimmed the first. Bookmarking for myself for later.

This post aims to dissect the power that exists in the Aggregate LINQ operator. I have realized that most programmers use it sparingly and have decided to put a couple of examples to clarify how you can use the Aggregate operator to perform a few tricks.

The author makes the assertion that the Aggregate operator is a bit confusing and rarely used. In my case, I know she's right. Good post to intro this guy to using Aggregates.

I've seen this way too much as well. Jeff Wilcox is right, please group methods by functionality and not visibility.

I found the error of my ways in the Clean Code book by Uncle Bob Martin. It is my new bible these days.

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 :)