Why Dynamic Typing in SharePoint is Suicide

I was browsing through Glyma today and noticed a comment on my own blog that requires some… explanation. As usual, the poster is an idiot, or at least makes an idiotic comment, but before we get there, a few things need clarification.


Yeah, you see, there’s this guy, Paul Culmsee, who is beyond awesome. He’s the guy that got me started writing and now, 20+ books later, I still find myself wondering if I’ll ever compare to Paul’s writing. 

In any case, his company has come out with this brand new thing called Glyma which I guess is a tool for mind mapping or dialogue mapping or whatever it is called. I don’t know too much about these things or its terminology, but I know one thing: It’s frigging awesome!

What it does is basically create a tree of knowledge (and no, you religious nutcases, not that kind of tree of knowledge) where you can refine information and knowledge down to its minute detail. I find myself browsing through the trees already created to explore ideas, review content, and most of all, laugh at some of the knowledge. And no, that’s not always the good kind of laughter either.

I’ll most likely come back to Glyma in far more detail, but for now, I want to point out one particular topic.

Note: You can check out Glyma yourself at http://www.glyma.co/. But don’t do it right now or you’ll never come back here to hear how to save yourself from embarrassment in a discussion on dynamic typing in SharePoint.

The topic in question is on how awesome SharePoint 2013 must be because it uses all the cool features of .NET 4.0 such as dynamic typing.

Dynamic Typing?

You may not know the innards of programming, but basically, there’s a somewhat religious debate regarding a topic called typing, of which there are two types, pun intended: static/strong and dynamic/weak.

Certain languages are dynamically typed by default, such as JavaScript, Perl, and to some extent and very optional, C#.

The difference may seem subtle but is very important in building stable systems. This fact seems to elude proponents of dynamic typing.

Essentially a statically typed language will make sure before you can even complete writing a piece of code that any properties or fields exist. A dynamic language couldn’t care less.

For example, let’s say you have an invoicing application in SharePoint with an item called Invoice that has a field called DueDate.

In a statically typed language, you cannot complete the writing of code if you mistype DueDate (for example if you write Duedate or dueDate) or if you write DueDate but the field does not exist. So, in a statically typed language it is impossible to misspell field names because your code will simply not run.

In a dynamically typed language, however, you have no idea whether the field exist when you write the code. If you misspell something, you won’t find out until your code breaks, which can happen at any point from now and until the sun blows up.

SharePoint in Particular

The particular comment in question is to my post on how SharePoint 2013 Apps Solve Non-Problems Only, readily available from your local search engine. The comment points out that only the .NET 4.0 runtime, which is available only in SharePoint 2013, supports dynamic typing and that users that want to target older SharePoint version misses out on that awesomeness.

[…]the dynamic keyword (dynamic would have been awesome in dealing with list item columns, a little puppy dies every time someone codes item["ColumnName"].ToString()). Always felt stuck in the past doing SharePoint 2010 development.

SharePoint encourages users to change their data so you may think that dynamic typing is an awesome idea. After all, what if you want to change your field names around? You may think that Duedate just looks better than DueDate so being dynamic must be great, right?


You see, dynamic typing, which is the stuff offered by the dynamic keyword, doesn’t actually change the code. It just ignores checking to see if you’ve written it correctly. If the user changes the field name from DueDate to Duedate, the code will still run; it will just fail or cause unwanted effects. You may not notice that because, you know, your developers ignore such mistakes on purpose because they’re lazy. Or stupid. Or Both.

I’m Not Lazy! Static Typing is Just As Bad!

Static typing won’t save you from users changing the names of fields. It won’t even save you, really, from misspelling of names. Like the commenter pointed out, it’s possible to write stuff like item[“Duedate”].ToString() (which turns the value of the field named Duedate into a piece of text). That’s because the “Duedate” part isn’t strongly typed.

That’s why you don’t rely on dynamic typing at all. Only an obtuse idiot or complete newbie would write item[“Duedate”] because if someone changes the field name, and that is supposed to happen, the code breaks, just like if you use the fancy new .NET 4.0 features and type item.Duedate instead.

The latter is just as bad, at least in SharePoint. It kinda works in other frameworks where field or property names aren’t changed, though. It’s still lazy.

Instead, real developers with proper understanding of problems such as this knows that you  rely on fixed or static properties of fields if there is a chance that non-fixed properties can change. Nothing dynamic. Fixed is reliable, stable, and dependable. Dynamic is not. Dynamic is lazy and unstable and takes away your freedom to change your field names.

Luckily, the Microsoft developers are usually good developers and know about simple problems like this. They have, completely free of charge, given you several fixed and static properties with which you can work as a developer. The InternalName property is my favorite and regardless of what the user does with regards to changing the display name of a field, the InternalName does not change. From the InternalName you can find the dynamic name reliably, but you can’t do it the other way around.

The point is that the dynamic keyword in .NET 4.0 isn’t useful in SharePoint at all. You still need to do exactly the same thing in .NET 4.0 as in .NET 2.0 to ensure your code is stable and reliable because, you know, SharePoint is quite independent of such things as fancy syntactic sugar or lazy developers.

Note: With the influx of newbie JavaScript developers and conversion of possibly decent SharePoint developers to SharePoint 2013 App JavaScript nutjobs, I’m expecting a ton of Item.DueDate code in the future because, you know, it’s more important to hang with the cool kids than to understand your job.

This, by the way, is somewhat of the same problem with content types. Newbie developers will reference content types by their names for example if they want to add columns to the Item content type. You can see this if you ever see SharePoint code anywhere that looks like ContentTypes[“Item”].FieldLinks….

If that’s the case, and you see such code in what your developer hands you, take that developer out back and beat them over the head until they can tell you why that is a stupid idea (and I’ve been beat over the head enough that you don’t have to point out that I’ve done this error in the past).


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

2 thoughts on “Why Dynamic Typing in SharePoint is Suicide”

  1. b:

    You know and I know that you’ve oversimplified the idea of dynamic typing to make a point. It’s not just about variable names. In JavaScript loosely typed means that a variable can be assigned a string and integer, whatever. Strict typing means that a variable has a type – like string – and can’t be assigned any other type of value.

    Also, your professional developer idea of using InternalNames is absolutely the smartest way to go. But even that doesn’t protect us from someone deleting the column altogether, which will break our code.

    When it comes right down to it, SharePoint has many loosely typed qualities of it’s own. This is only one reason developing on top of it can be a challenge. Good SharePoint developers recognize this. They write good code that works, understanding that they may need to fix it when something changes. They comment their code well and write documentation to help themselves or others to make those adjustments over time.


    1. > Also, your professional developer idea of using InternalNames is absolutely the smartest way to go. But even that doesn’t protect us from someone deleting the column altogether, which will break our code.

      That’s why you handle those problems differently. It still doesn’t yield a single point to the weakly typed arguments that seem prevalent these days.


Leave a Reply

Your email address will not be published.