Taking a page from Python

This incarnation of my blog began with my foray into the wonderful world of C# and ASP.NET MVC, but in a previous life, I was a Python developer. One of the first things virtually every Python developer is exposed to is PEP 20. PEP stands for Python Enhancement Proposal, and there's hundreds of them, spanning the life of Python, and essentially documenting the development of Python as a language. As the name indicates, PEPs are essentially specs for Python language features or, at times, documentation of preferable styles and conventions (best practices). In general, they're a great feature of the language, but PEP 20 all the more so, as it succinctly and perfectly manages to encapsulate not just good programming practices in Python but in virtually any language.

PEP 20 - The Zen of Python

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

It never ceases to amaze me how much C# code I come across which would benefit from knowledge of this mantra. More than that, I'm amazed by how many problems C# developers have that would simply dissipate if they employed these practices. For example, I recently came across a question on Stack Overflow where the asker wanted to essentially prevent a particular property on a class being bound when sent in the request body of certain requests. They had settled on creating a custom model binder to solve the issue.

Now, I consider custom model binders an anti-pattern. I've been developing in ASP.NET MVC for 4 years and I have never once needed a custom model binder. It's great that you can create one, but the thing is that I've just never ever seen a good use for one. Invariably, whenever one is employed, the issue could have been solved in another, simpler way. Almost without fail, they are a crutch, glossing over the root problem.

This particular situation was no exception. The correct approach is to simply not include that property on your model. In other words, if you need to only accept a subset of properties, then create a class with just those properties. (Simple is better than complex.) This also has the side effects of increased readability (Readability counts.) and it makes your code self-documenting (Explicit is better than implicit.).

That's three violations of PEP 20 in just one single issue. Yes, C# may be a very different language than Python, but I think C# developers could definitely learn a little something from it.

comments powered by Disqus