Skip to main content

Enhancing code readability

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 first saw the notation "1.Seconds()" in Fun with extension-methods (and similar notations for the DateTime class in DateTime extensions), and have since played around with it myself to be able to write things like "myDateTime.IsBefore(1.Hours().Ago())" instead of mathematically manipulating TimeSpans and DateTimes to death.

This time I'd like to share another C# fun fact that has to do with readability - conversions between method groups and delegates.

Suppose we have the following method:

(One could even go further and have it like so:

I'd say it's a bit overextending, pardon the pun, but that's a matter of personal taste I suppose.)

A trivial usage of GetPeriodicTimer would be:

However, since there is an implicit conversion between method groups and delegates you can let the compiler do the thinking:

Imagine a scenario where you'd like to have two actions invoked whenever the timer elapses. You could, of course, create a separate method and invoke your two actions from within, but that seems a bit off. We'd probably want to write something like:

However, this is the point where the compiler won't play ball and remind you that after all, you're using method groups, not actual delegates, and since the '+' operator is undefined for method groups, things go bad.

In order for the compiler to pick up on what's going on, all we need is to explicitly convert one of the method groups to an action (any of the two will do the trick):

Now the '+' operator has a delegate as the left hand operand and a method group as the right side operand - which it can automatically (and implicitly) convert to an action. Since the '+' operator is well defined for delegates, we're off the hook.

Another benefit is that further actions can be added as method groups as well:

Though if you have more than just a few, it's probably best to extract them to a separate method after all, for the sake of... well, enhancing code readability.

Comments

Popular posts from this blog

Sending out Storm metrics

There are a few posts talking about Storm's metrics mechanism, among which you can find Michael Noll's postJason Trost's post and the storm-metrics-statsd github project, and last but not least (or is it?)  Storm's documentation.

While all of the above provide a decent amount of information, and one is definitely encouraged to read them all before proceeding, it feels like in order to get the full picture one needs to combine them all, and even then a few bits and pieces are left missing. It is these missing bits I'll be rambling about in this post.

Dependency Injection - The good, the bad and the ugly

The Good
Dependency injection (DI, a.k.a IoC - inversion of control) is a well known technique to increase software modularity by reducing coupling between modules. To provide the benefits of DI, numerous DI frameworks have arisen (Spring, Guice, Castle Windsor, etc.) all of which essentially give you "DI capabilities" right out of the box (these frameworks tend to provide a whole lot more than just "DI capabilities", but that's not really relevant to the point I'm about to make). Now, to remove the quotes around "DI capabilities", let's define it as a DI container - a sack of objects you can manipulate using a provided API in order to wire these objects together into an object graph that makes up your application.

I've worked on quite a few projects employing Spring, so it will be my framework of reference throughout the rest of the post, but the principles and morals apply just the same.