Skip to main content

C# 2.0 - Nullable Types

It's 3 am and i don't feel like sleeping. I've been helping a friend to work on his code and now i'm only partially tired. Well, why not continue with my series on the evolution of C#? Let's do it!

So, this time i'm going to talk about nullable types. Everybody used them already, but back in .Net 1.0 they didn't exist. How did you represent a "no value present" value? Sure, string can have null, but null is different than empty, right? How do you represent an empty numeric type then? You check if it is bigger than 0? Well for some cases that's just how developers did it. Either that or create a constant value that represents a "no value". But, to me, that is not expressive enough.

Basically, a nullable type is only a non-nullable type wrapped in the System.Nullable struct. This is a generic struct, so it makes use of the Generic features of C# 2.0. The struct is very simple, it contains only a HasValue and a Value property. Both are very explicit and this makes it easy to work with. As for the sintax, check this out:


The above two lines have the same meaning. You can assign null to both of the variables and use the same properties. It's just syntactic sugar!
In my opinion, nullable types bring the following benefits:

  • They add simplicity when dealing with databases. In MS SQL Server, you can have a null int, numeric, or whatever you like.
  • They can transmit the meaning of a parameter/variable more clearly. If that parameter is optional, just let it be nullable (although we have optional parameters too, now).
Note that you cant have nullable reference types (does it even make any sense?) nor nullable inside a nullable (double null?). This is a little feature that was not so noticed by some people i know and therefore is a little underused. 

Thanks, till next time!
Labels:

Comments

Post a Comment

Popular posts from this blog

From crappy to happy - dependency what, now?

Following the introduction on this series on a previous post, we will now talk about dependency injection and how it has the effect of allowing for more testable code. Sometimes when I talk about this concept it is difficult to explain the effect that applying it might have on the tests. For that reason I think it is better to demonstrate with a near-real-world situation. Obviously, keep in mind this is not real code, so don't worry about the design or implementation details that don't contribute to the point being discussed. The code As you can see, it is simple. There's a class called ShipManager (what else?) that receives position updates for the ships. It keeps the last position reported from each ship and does some calculation to see how much the ship moved. It assigns some values to the update and finally it persists the final version of the update. How do we start testing? When you think about it, tests are dead simple. A test either passes or it doesn...
Post a Comment
Read more

The repository's repository

Ever since I started delving into architecture,  and specifically service oriented architecture, there has been one matter where opinions get divided. Let me state the problem first, and then take a look at both sides of the barricade. Given that your service layer needs to access persistent storage, how do you model that layer? It is almost common knowledge what to do here: use the Repository design pattern. So we look at the pattern and decide that it seems simple enough! Let's implement the shit out of it! Now, let's say that you will use an ORM - here comes trouble. Specifically we're using EF, but we could be talking about NHibernate or really any other. The real divisive theme is this question: should you be using the repository pattern at all when you use an ORM? I'll flat out say it: I don't think you should... except with good reason. So, sharpen your swords, pray to your gods and come with me to fight this war... or maybe stay in the couch? ...
2 comments
Read more

The evolution of C# Part One - The beginning

Today, let's talk about some history. Not that World War history, but the history and evolution of C# as a language. I would like to analyze the principal parts in one of the mainstream languages of mass production in today's software. Beware that most of what i am about to say is the fruit of much research, in part because when C# and the .NET became available i had not written a single line of code yet, so you can say that i am a newborn in this world. I'm inclined to change that, though, but every new discovery is done with much enthusiasm on my part, and i'm very proactive, which sometimes may upset my colleagues. One of the reasons i'm writing this article - and this blog all the same - is because i love to learn new things and share it with others. Enough talk, let's get to the point! The beginning of .Net The .NET platform brings a brand new and fresh way of programming your applications. Microsoft created the term "Managed Code" to refer t...
Post a Comment
Read more