kick #2

Here I'm continuing what I've started the last time. Coding: technical aspects, part #1 Everyone knows, there are best practices for handling exceptions. One of the design guidelines for exception-handling says: "Avoid handling errors by catching non-specific exceptions, such as System.Exception, System.SystemException, and so on, in application code." That's a great piece of advice (yes, you can never handle all the exceptions), as long as you don't use .Net Framework (.Net FW). One reason for this is you never know for sure which types of exceptions can be raised by the code (MSDN or intellisense not always help here, believe me, I've dug though some call stacks pretty deep just to get the exception types). There are other problems: 1) invoking same methods can produce different types of exceptions in different versions of .Net FW (see how the Mutex class behaves in v1.1 and v2.0). So if you're writing anything forward-compatible (that's you're planning to move to the next FW version someday), you'll have to retest every piece of Framework code for exceptions before actually migrating to the new FW. So some developers prefer catching non-specific exceptions and then filtering irrecoverable exceptions and throwing them no matter what -- this breaks another design guideline which says "Do not exclude any special exceptions when catching for the purpose of transferring exceptions". BTW, MS guys themselves do love filtering exceptions. 2) .Net FW throws exceptions of type System.Exception (WMI is written particularly badly and does just that in many places) -- how I'm supposed to _handle_ this ugly stuff in a nice way, I wonder? Therefore, most of the time we, developers end up either filtering exceptions by type (by throwing only some of 'em) after cathing the most general System.Exception or even worse -- not filtering and just catching. It's just impossible to do proper exception handling at a 100% in .Net FW at the moment. I see only one way through this mess: make all developers decorate every method with attributes which tell what types of exceptions the method throws (throwing SystemExceptions or just Exceptions must be prohibited).

A kick in the arse

Looks like the IT industry is going to take a break for tea and biscuits in coming years. And you know what? -- we sure as hell asked for this. We needed a major kick in the ass to get real, and here it is finally. Unreadable code What makes me think we're in deep shit? Well, I've worked on a few projects last 18 months for a large US company that loves to outsource, and I had to take a deep dive into some of .Net Framework's source code. Some of our projects we had to build over those projects other outsourcers had already completed. I've seen a lot of scary stuff (more on .Net later, in other posts), tons of barely readable texts. Yes, it's texts we're actually writing, guys, think twice about how you're gonna name your next class, next method, even next local variable. I'm sure that the vast majority of software developers is not even up for the job -- I mean crafting readable software not only takes a good developer, it takes one that has gut-feeling for simplicity, one that has his/her way with words, it might even take one that is not a developer at all. Right now maintainability of the vast majority of applications is lower than negative infinity. Make 'em usability tests if you're not sure you've created a good class (after the design meeting) -- drop a class diagram by your colleagues, make your manager approve this "time-waster", step up. I thought of giving a little (rather ill) example. Meant to tell you about how much time I've killed over a method which was named something like PrettyPrintAnErrorMessage(...) -- and it actually filtered exceptions inside, threw some kinds and swallowed others. The point of the story would have been: give a meaningful name to a method -- the one saying what the method _really_ does. I called that example rather ill because naming was not the only problem there -- it's just so not the way to handle exceptions (me and my guys had to do helluva job when we've found out about that _pretty_ printing). I decided to cut the story short because the computer science, the OO theory itself, C# language construct's names present some bigger issues. I'm gonna take the singleton pattern to make a point. You have to define the singleton as a class, right? But it's not a class at all -- a class is "a group, set, or kind sharing common attributes". You see where I'm going with this? The computer science, the OO theory, C# encourages us to write crap that only we understand, encourages by having a vocabulary where many words (like class) we might use in everyday life have odd meanings. By making the science's vocabulary (every science has one) simpler, by removing those cross-vocab intersections, we could make texts -- I mean code -- more readable. But it's a little late for that change, isn't it? The only thing we can do, as our part of the job, is to admit: we, software developers, are regular people, and so is the vocabulary we're using most of the time. Leave with it. No fancy names, just plain and simple stuff. I mean this: even the names of domain classes are to be reviewed if they're cryptic. Domain experts are regular people too, they may suck at giving names to things -- as much as we suck at naming classes today.