Coding rules, self-debate and formatting a string in your view

I was thinking to myself about how I wanted to format dates in a particular project recently. I said, "Self, is it wrong to use an extension method inside a view to do this?" I was clearly distracted with something else, so I didn't answer, but then The Gu did the Twitter to this gem by a guy named Chris, and he says it would not be cool.

I want to make a case for two things. The first is all the cons that come up in Chris' approach (despite otherwise being a great set of rules), and second, why rules make you do all kinds of crazy things.

A lot of people will make a case for generating view models that have absolutely everything in its displayable form, short of for loops and conditionals around permission type stuff. I'm not entirely sold on that, for a number of reasons. Where do you draw the line? I mean, this suggests tossing out HTML helpers too, and I can assure you I have no interest in doing that. I also get annoyed with all of the objects that require a ton of transformation just to get you from the data store to the browser. We already find ourselves having data transfer objects and entities we like to play with, but do we need yet another thing in between? If I'm building a forum, I just assume have a collection of Post objects instead of yet another property for PostsWithFormattedDatesAndOtherStuff. You can use something like AutoMapper, but I'm already seeing worlds with enough references to binaries I don't own making maintainability a pain (DI containers, ORM's, unit testing frameworks, caching stuff, mocking frameworks, etc.). Besides, that's more stuff you have to configure and test. And yes, a fluent interface is still configuration.

At the end of the day, I'm going to roll with the extension method, which is no different than any HTML helper. In fact, I can actually make it an extension method to HtmlHelper, if it will make people feel better. I can test it quite easily, so where's the problem? Do it once, test it, done. It beats all of the extra work for more models, more entities, more stuff to test.

I'm not dissing Chris' rules. I think most of them are pretty solid guidelines. But it's the rules rules rules that get you into trouble.

That leads to my second issue, the one about rules making you do crazy things. One of the things I've noticed when mentoring inexperienced developers is that they often respond to suggestions with comments like, "Well I thought you had to do this because of [insert some academic "rule" here]." Developer types like to work in a realm of scientific absolutes, but I would challenge you to think more about the spirit in which a rule is made, and make it more of a guideline. In my date formatting example, I believe that I'm not causing any cosmic armageddon by violating a separation of concerns, I'm not harming testability, I'm not repeating work, etc. Would I make the same decision in a bigger project that I don't entirely own? It's hard to say, but again I'd rather consider the spirit in which the guidelines were made instead of being dogmatic.

So learn everything you can about best practices and even make some mistakes. Adhere to the spirit of guidelines and leave some room for interpretation. And above all, ship something today!