Noisy code does not equal clean code - Derik Whittaker - Devlicio.us

Derik Whittaker

The Lounge

Wicked Cool Jobs

Syndication

News

Blogs I Read

Current Readings

Archives

Derik Whittaker » Noisy code does not equal clean code

Noisy code does not equal clean code

Today I was having a conversation with one of the developers on my team (btw, this guy is going to be a rock star) and I made that statement to him that I thought we had some noisy code. The context around this conversation was with our usage of AutoMapper (which I love so DO NOT take this as a slight against the tool) and how by default using AutoMapper exposes too much noise and I do not like it.

When I made this statement to him he was not 100% sure what I meant, so in place of having a one-off conversation with him I thought I would try to explain my thoughts to the world (hey, that is the point of blogging after all, right).

When using AutoMapper to map objects from one type to another in your code you need to implement something like below:

var someMappedDto = Mapper.Map<SomeModel, SomeDto>(someModelInstance);

If you look at the code there is a bit of noise here in my opinion. So what do I mean by noise? I consider anything in my code that gets in my way or does not provide me direct feedback as noise.

In the line above I consider the following noise:

Mapper.Map – I do not like this because having Mapper.Map sprinkled all over my code base just means that my code has too much knowledge of the actually mapping library we use, this is noise. Hey, it was for this basic concept that the Common Service Locator was created to help prevent
Having to provide both the source type AND the destination type – The source type should be able to be derived from the source object instance (in cases where you do not want to use the mapper for some child type of the source type). I concede that you do need to provide the destination type other wise we would have no clue what you want in the end
Having to provide the source type instance in the constructor.

In order to reduce the noise, and make for cleaner code I would like to see something like

var someMappedDto = someModelInstance.Map<SomeDto>();

In my humble opinion the code above is cleaner and more concise. The code above has less noise to distract me from my coding efforts. In particular the code above addresses my 3 issues in regards to the noise

Now I am abstracting my mapping library of choice (AutoMapper) away into an extension method some place, thus giving me a clean abstraction layer
I do not need to provide the source data type as it can be inferred from the instance itself (yes, only in the case where the actual type being used is the type I want)
No need to provide the type to be mapped from (well not directly)

To me noise free code is clean, concise and easy to read.

Till next time,

Posted 02-25-2010 7:16 PM by Derik Whittaker

Filed under: Opinion, Craftsmanship

[Advertisement]

Comments

Henning wrote re: Noisy code does not equal clean code

on 02-26-2010 3:57 AM

Rarely do I see blog posts with code that is simple and to the point. This is one of those posts that makes you want to slap your forehead yelling "doh, why didn't I think of that?".

We're injecting a custom mapper interface throughout our code that abstracts away Automapper so that we can unittest better. However, this makes things harder to change and stub.

I will definitely look into this and see if we can do something similar.

Thanks :D

ArnisL wrote re: Noisy code does not equal clean code

on 02-26-2010 5:04 AM

Code noise is hyper global problem. Not many pays any attention. I think it's one of the corner stones one must remember when writing every single line of code.

Seth Petry-Johnson wrote re: Noisy code does not equal clean code

on 02-26-2010 8:50 AM

I agree, I think it's much easier to read AND write code that follows the instance.DoSomething() pattern instead of the StaticThing.DoSomething(instance) pattern, so I'm a huge fan of extension methods.

That they give us an extension point for swapping out framework features, or that they make our framework features more discoverable via Intellisense, is icing on the cake.

alberto wrote re: Noisy code does not equal clean code

on 02-26-2010 11:49 AM

So what you propose is adding extension methods to Object? Now imagine every library doing that. No thanks. Why don't you create it for you project? If you have a base class, common/marker interface you could even apply it to that.

Source type inference would be cleaner, i agree.

Eber Irigoyen wrote re: Noisy code does not equal clean code

on 02-26-2010 4:12 PM

I don't like to use an extension method for that purpose, like @alberto mentions, that would create caos, I think you may be overengineering here

Andriy Buday wrote re: Noisy code does not equal clean code

on 02-26-2010 7:30 PM

Moving

Mapper.Map<SomeModel, SomeDto>(someModelInstance);

to the extension method like:

public static TDest Map<TDest>(this SomeModel model)

{

return Mapper.Map<SomeModel, TDest>(model);

}

is a bit like moving noise from one place to another.

But I still agree that this makes us decoupled from specific mapping engine.

Hadi Hariri wrote re: Noisy code does not equal clean code

on 03-02-2010 1:30 AM

@Eber, @Alberto

RhinoMocks adds an extension method to object. It would only cause chaos, if you were to call it that, if you were to use every library in the world in your project that does this.

irislogic wrote re: Noisy code does not equal clean code

on 03-02-2010 6:16 AM

Noisy codes seriously bother me! Makes me want to go and change it for them, but of course I need to get paid.

Matt Hinze wrote re: Noisy code does not equal clean code

on 03-02-2010 8:44 AM

You can always take a dependency on IMappingEngine, or decorate it to add the behavior you want. Also, AutoMapper is on github and is accepting contributions.

Matt Hinze wrote re: Noisy code does not equal clean code

on 03-02-2010 8:51 AM

Also, and I don't know what they do now, but some dynamic proxy libraries, at one point, did not return the proxied type from GetType(), but rather the proxy type.. I think that's why the explicit call is there.

Derik Whittaker wrote re: Noisy code does not equal clean code

on 03-02-2010 8:55 AM

@Matt,

Oh I know i could submit patch, but not sure my 'concepts' are what everyone is looking for.

And again using Automapper in this post was ONLY to talk about noisy code, not a reflection on the library.

Sponsors