I came, I coded, I debugged.

1. This module can't be unit tested, it's too [ insert-adjective-here ]. If it's too [ insert-adjective-here ], how do you even know it's working in the first place? And what about after we extend it with a new feature? 2. Breaking logic into methods incurs a performance hit. So does inheritance, and separation into classes. Does this mean your design should consist of a single class with a single method where all business logic is placed? 3. Commenting code is time consuming and hinders development. Same goes for going to the bathroom, but you don't see people skip that, do you? 4. Coding conventions are too rigid, I'll call my fields whatever I want. Now that's just an excuse to write ugly code.

I'm a big fan of easily readable code, in fact, my appreciation for code that reads almost English has only grown over the years. Extension methods in C# allow for some nice tricks to take place in this regard.

I'm not sure the case is that clear with this one. Disclaimer : I'm by no means a ClearCase Guru. I'm just someone who strongly believes source control management (SCM) systems should be perfectly usable by people who are not their admins. ClearCase begs to differ. After using it for almost a year, I'd like to beg, though not to differ, but for someone to put me out of my misery.

If you ever got to tango with performance counters in C# (+1, they can be very useful) you might have noticed that the current API leaves much to be desired. Things can get even more cluttered when you have a bunch of them. You have to store the name, help string, and type for each one so you can feed it to the API later on. You'll also need to store an instance for each counter so you can have its value updated. The other day a colleague of mine mentioned that the task of adding a new counter becomes a chore . The good news is, you can make your life easier.