I like to code as little as possible.

I am not referring to how much time I spend coding, but more how terse and compact ("neat") the code is. If it's growing hairs trim them. If it's more than one complete thought, extract method.

One thing that's been causing me to grit my teeth a lot lately seems to be caused whenever I hear the term, "error handling," usually like, "look at that code! it's crap! There's no error handling!" where, in my opinion, error handling has no business being. It hurts even more when the person is someone I respect and otherwise agree with on all matters technical.

Extraneous error handling seems to me to be one the fastest ways for code to go from simple and clean:

to stressed out and hairy:

For a long time, when I first started learning .NET, I had this C++/COM baggage I brought with me, where I thought HRESULTs and IErrorInfo was the right way to do error handling. I had brief experience working with java and remember being shocked at how some java programmers thought the ratio of "catch" to other keywords in their programs should be approaching 1:1. I had concluded that "try" was bad, and .NET was worse off because of it.

Then I read what the P&P Team thought about the exceptions and breathed a sigh of relief. I had my strategy:

Exception Propagation

There are three main ways to propagate exceptions:

• Let the exception propagate automatically

  With this approach, you do nothing and deliberately ignore the exception. This causes the control to move immediately from the current code block up the call stack until a catch block with a filter that matches the exception type is found.

...

(emphasis mine)

This is how I think 99% of code should handle exception, just as it's how I think 99% or bystanders should handle high speed car chases. Don't do anything! Let someone else who knows what they are doing handle it.

For this to work, you often need to alter other bad habits as well, such as instead of "try { DoSomethingToFileThatMightNotExist(fileName); } catch (FileNotFoundException) { /* ignore */ }" say "if (File.Exists(fileName)) DoSomethingToFileThatMightNotExist(fileName); }".

This also helps with debugging. Who likes it when you turn on "Stop when exception is thrown" in the debugger only to find there are a gazillion exceptions you don't care about being caught by code that ignores them?

All this leads me to see "try" as a code smell. I look extra hard at code with "try" and even harder at code with "catch". If I can, I refactor them away as quickly as I can.

Ideally, a user facing program should have only one place where errors are handled: the place where it decides how much to show to the user and how much to report to you via some other channel.

This helps me keep my code small, neat, and clean.

 

This weblog post argues that IoC should be used in moderation, and for purposes of unit testing in particular can be replaced with reflection - i.e., instead of expressing your class's dependencies in constructor arguments or properties for the IoC container to fill, express them through private variables, make them self fulfilling ("private _myThing = new Thing();") and use reflection to change their values during unit testing.

I am just starting to get serious mileage out of IoC, Castle.Windsor in particular, and also the ObjectBuilder stuff in CAB. I am really liking this style of programming, and really do notice an improvement in how easy it is to set up unit tests and keep dependencies under control.

In a way, I recently moved to IoC - that's why I like to have all my unit tests in-class. Using reflection to set dependencies in fields in an object under test is way more cumbersome and error prone than Mocking some interfaces and passing them to the constructor, or implementing the interfaces with some test classes, and using those (both of which I have to assume you were doing anyway - I know I was.)

I don't like the having-important-code-in-XML part, but the containers I have used so far have not been overly complicated. It's a small price to pay for the structure and modularity it lends you applications.

Source: Getting rid of IoC
Originally published on Sun, 10 Sep 2006 22:55:34 GMT

 

Last night I was working on something and suddenly found myself needing about 30 really simple ActiveRecord classes. I figured it was about time to stop writing these manually each time.

Looking at the CastleProject.org site, and seeing that the status of ActiveRecordGenerator was frozen, I briefly considered writing my own little tool (or just modifying ActiveRecordGenerator as needed) to do the job. After another 10 minutes, I finally broke down and made a CodeSmith template (we've got CodeSmith, but for some subconscious reason I keep avoiding using it.)

This was fairly straightforward, and after 20 minutes or so, I had the template I wanted, and started generating classes. After another 20 minutes I had added some things I missed the first time and everything was great.

After completing this, I looked at what I had done, and found myself thinking: this is alot of cruft.

Let me mention that all 30 classes had basically the same set of properties. I briefly considered writing a generic class, but didn't think there would be a way to get the name of the class into the '[ActiveRecord("MyTableNameIs")]' attribute. That, and a small handful of special rules, were the only things different about these classes.

I was thinking: A lisp-like macro would have been really useful. Why don't we have lisp macros in OO languages like C#? I've always fealt (but not agreed) that it's because OO leads you to composition instead of code generation. I could have written one base class with the properties I wanted, then 30 derived classes with the right names and attributes. That is still too much typing, though, and I would have used code generation anyway. I chose not to relate these classes, as they are not really related in this domain anyway, only functionally and structurally related.

I am not sure what the best answer to this type of design problem is, but I know I haven't found it. Code Generation is a jack-hammer in the face of the problem of code duplication caused by imperfect design. It gets me through the barriers, but the barriers were trying to tell me something.

Frameworks and tools (like ActiveRecordGenerator, or even better - Streamlined) that generate applications based on meta data are becoming very popular. Are these tools just reactions to the lack of good DSL tools or lisp-macro-like facilities - i.e., why am I writing my C# application in Code Smith templates and not in C#?

 

I went to dotnetusers.org's meeting tonight for a WCF presentation. The presentation wasn’t as deep as I had been hoping. I am trying to get back into this stuff and need some oomph. After seeing more and more really awesome presenters, I am really starting to hate power point.

There were a few more people than at ssound.net in Olympia, but if we keep things going at ssdotnet, we can take 'em.

Ted Neward was there and some other people I almost recognized from somewhere.

Jason Haley indicated he was going, but I don’t know what he looks like (ok, look, there is a picture here…but I don’t think I saw you.)

For a large chunk of my developer career (from about 1999~2004) I was really, really interested in distributed systems. I remember when the ATL developer’s mailing list morphed into the SOAP mailing list (or maybe I morphed into someone reading the SOAP mailing list.) I loved COM+. I loved web services. When I first heard about Indigo, I was soo excited.

Then something kind of weird happened. I started seeing people actually building apps with XML Web Services. They sucked.

The last straw is still unfolding into my life. At work we are doing this huge, uber-high-stakes integration project with a third party application. The API blows chunks. I don't (really do) want to get into details, but someday, after I have filled my lungs with this, I will have some stories to tell, I am sure.

This is a high-visibility project and my boss is heavily leveraged. He (we) need this to work out well - but I just know something is wrong. All the signs are there. The first sign was when I saw they had a XML Web Service (...kind of thing....ahem) that returned a "cursor" (and I knew the backend database was Oracle...hmmm...cursors...Oracle...web services...)

Other signs:

• They've been talking/planning/meeting 20+ hours a week about it for almost a year, but ask any two people and you'll get 3 different answers about what they are doing and how it all works. The tracking error grows geometrically as you move away from the source.
• Every developer looks at the service interface and sees something different (I call them bad XML web services, but someone else might call it floor wax.)
• I sense a lot of apathy from some of the people that are supposed to benefit from this.

reduced:

• Lack of vision
• Lack of cohesion
• Lack of perceptible benefit

So what does this have to do with WCF? The reason I am having trouble getting back into this is that it is too far gone from reality. 3 years ago, it kind of sounded plausible that we would have all these people building loosely coupled apps with WS-* and the hundreds of specifications and rules they would have to learn to make it work right. Now...it frankly sounds kind of naive.

WCF makes it really easy to do things really right for Windows developers. For java developers there are things like this too, but when you read white papers from IBM or Oracle, you just know they aren't talking about exactly the same things. There is some kind of disconnect that keeps everybody from agreeing on things and just building stuff - and in the confusion, vendors like ours are born.

Being able to move up the food chain by claiming to support, "integrated, enterprise, solution-oriented, xml, distributed, _standards_based_, web services," is a boon to the sales forces of companies like this. Before they had libraries based on COM, Java, maybe perl or something, the sales guys didn’t know what any if that meant, and everything sort of worked. Nowadays you can put lipstick on a pile of XML pasta and sell it as a feature. All the sales guys “know” what that means, but not the developers.

I know we will be using WCF to unify how we build distributed apps in-house and I know some vendors will do the same thing. But we still have a long ways to go in integrating applications.