I am quite certain that plenty of resolution randomizers exist, so I will just jump straight in to things. Here is a link to a resolution randomizer created using Silverlight.
Now everyone will feel sorry for my coworkers who have to listen to this, because the random resolution machine said I have to.
Have fun celebrating the coming of the new year everyone.
A couple of days ago I was working on some code when I noticed a comparisons of two DateTime? variables. So I wondered what would happen if either or both of those variables had gotten null values. Since I had never tried it before I figured I would just take a couple of minutes and test some things. Since I already had visual studio open I just created a unit test and wrote some code in there to test the behavior. I've not done it in a console application since it is easier for most people to use the console app version of the code.
So the first thing to do is to create a few Nullable DateTime variables. I then wrote a small amount of completely unnecessary code. I did this to assure the readers of this post that the assumption that the Nullable variables' HasValue properties is correct. I then proceed with a bunch of test cases some of which are unnecessary, but I believe they help demonstrate the point.
My task for readers of this post is to try to figure out the results of this code before reading the answer below.
int? lesserDateTime = 1; int? greaterDateTime = 2; int? nullDateTime1 = null; int? nullDateTime2 = null; if (!lesserDateTime.HasValue || !greaterDateTime.HasValue || nullDateTime1.HasValue || nullDateTime2.HasValue) { throw new Exception("Something is very wrong here!"); } Console.WriteLine("\n lesserDateTime > greaterDateTime = " + (lesserDateTime > greaterDateTime)); Console.WriteLine("\n greaterDateTime > lesserDateTime = " + (greaterDateTime > lesserDateTime)); Console.WriteLine("\n lesserDateTime == lesserDateTime = " + (lesserDateTime == lesserDateTime)); Console.WriteLine("\n lesserDateTime > nullDateTime1 = " + (lesserDateTime > nullDateTime1)); Console.WriteLine("\n greaterDateTime > nullDateTime1 = " + (greaterDateTime > nullDateTime1)); Console.WriteLine("\n lesserDateTime == nullDateTime1 = " + (lesserDateTime == nullDateTime1)); Console.WriteLine("\n greaterDateTime == nullDateTime1 = " + (greaterDateTime == nullDateTime1)); Console.WriteLine("\n nullDateTime1 > greaterDateTime = " + (nullDateTime1 > greaterDateTime)); Console.WriteLine("\n nullDateTime1 > lesserDateTime = " + (nullDateTime1 > lesserDateTime)); Console.WriteLine("\n nullDateTime1 == greaterDateTime = " + (nullDateTime1 == greaterDateTime)); Console.WriteLine("\n nullDateTime1 == lesserDateTime = " + (nullDateTime1 == lesserDateTime)); Console.WriteLine("\n nullDateTime1 > nullDateTime2 = " + (nullDateTime1 > nullDateTime2)); Console.WriteLine("\n nullDateTime2 > nullDateTime1 = " + (nullDateTime2 > nullDateTime1)); Console.WriteLine("\n nullDateTime1 == nullDateTime2 = " + (nullDateTime1 == nullDateTime2)); Console.WriteLine("\n nullDateTime2 == nullDateTime1 = " + (nullDateTime2 == nullDateTime1)); Console.WriteLine("\n");
Answer below.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
And just to show that this has to do with Nullable really and not the DateTime part, I did the test with int? also.
This is why you need to be a little bit careful with Nullable types. Make sure that you are always checking the HasValue property when working with Nullable types so you can handle the situation in the desired fashion. If you didn't know or check the type of that variable the results could be disastrous.
Don't make too many assumptions about behavior. I asked a few people what they might expect to get when comparing with the null value, and they guessed that the null would be treated as the default value for the data type. That guess makes a lot of sense, but it is not the case. Notice that every time a null was involved the result was false. The only time this is not the case is when comparing the equality of two null values.
As a final note I will say that if you want to do comparisons of Nullable values I recommend doing the following. Since Nullable's are a little bit special, we need to compare them this way.
Console.WriteLine("\n Nullable.Compare(lesserDateTime, nullDateTime1) = " + Nullable.Compare(lesserDateTime, nullDateTime1)); Console.WriteLine("\n Nullable.Compare(nullDateTime1, lesserDateTime) = " + Nullable.Compare(nullDateTime1, lesserDateTime));
If we don't do the comparison in this manner we are likely to get the above unexpected results. If you want to see the specifics of the Nullable.Compare method, read the MSDN Nullable.Compare documentation.
I am somewhat partial to a few of the posts from my previous blog. For some of these posts, I just like the post, some the content about which the post was written, and some were just popular posts.
Installing SQL Server Management Studio with SQL Server: My most popular post is one written about a painful experience installing SQL Server's client tools. Sadly the popular post is out of date. My first post about the topic I found a solution that worked and managed to install the software. I late found out that there was a better way and I updated the post. The problem is that Google continued to send traffic to the old one. For my blog it was a pretty popular post. it has had over 25,000 views.
The original version - Installing SQL Server Management Studio with SQL Server
The current version - SQL Server Client Tools Installation
Visible Whitespace in Visual Studio: Another post written about a traumatic experience was when I accidentally used a keyboard shortcut and enabled visible white space. It caused a blue dot to show for every space character in visual studio. Wow was it hard to read my code with that on. Well I Googled for it, and at the time I didn't receive any results. There are some now my post is one of them. I also didn't notice the option to turn it off. I used an algorithm I like to call brute force to figure out the keyboard shortcut I typed. It was Ctrl + E + S. Comments let me know of a bunch of other ways to solve the problem for different configurations and versions of Visual Studio.
Visible Whitespace in Visual Studio
Return Within a C# Using Statement: IDisposable objects are nice to work with. I prefer not dealing with external resources, which is generally what you're doing with disposable objects, but having this interface makes it a little bit nicer. I wrote a post telling people it was safe to return from within the using statement, because the using statement will make sure that the object is disposed. In the lifetime of the post only one person actually challenged me on it and asked me to provide code showing that what I said is true. I of course responded to that comment and then posted a response on this blog. My response includes sample code showing that using statements make sure that the object is disposed.
If you like the second post make sure you thank Lambros Kaliakatsos for commenting on the first one.
The original post - Return Within a C# using Statement
The follow up including sample code - Returning From Inside a Using Statement
Performance with DropDownLists and ViewState: One thing that it seems a lot of ASP.NET developers still don't understand very well is ViewState. Page lifecycle stuff seems to really be fueling the MVC craze these days. I wrote a post talking about how ViewState can hurt the performance of your applications if you let it get out of hand. The example I used is the drop down list, but it can certainly get a bit crazy from grids, repeaters, etc. I wrote an article basically saying that you should try to avoid ViewState if you're going to have too much of it. I later followed up with a post about how to use a DropDownList without ViewState. Some people are concerned that you will not be able to use the SelectedValue property, but you can if you wire it up correctly. It is all about understanding that painful Page Lifecycle.
Performance with DropDownLists and ViewState
Using a DropDownList without ViewState
There are plenty of other posts I like in there, but I think I've bored my readers enough for one day. I've got a couple of posts lined up which should be a little bit more interesting than this one, so keep reading. As always, have a great day.
Most people who know about Test Driven Development have heard the phrase, "Red, Green, Refactor". When it comes to actual implementation of this technique there seems to be a bit of a disagreement. By following the rules of RGR we all agree that we start by writing a failing test (Red), we write the code to make the test pass (Green), and then we make the code better and remove duplication (Refactor). The point of contention I hear about most often is in the Red stage. Some people say to write the failing test before writing any code. Some people say that you can make a skeleton of the code and write the test for that.
In practice I tend to agree with the people that make the skeleton code first. I really just don't like having the compiler error be how my test fails. What I do instead is create the code I am going to test and have it throw a NotImplementedException. This lets me make sure the test is failing so I am sure to flesh out the code.
Now I can certainly see reasons to do both. That is just what I prefer. One interesting problem which can arise from doing my method is the following. Say that I am going to create a new method on a class, so I create the method and write the failing test. Perhaps this is a non-tested project I am working on, so only the new stuff is tested. I write my code and everything passes now. But I've created a new bug. How?
I am kind of cheating here because there is a compiler warning. Since not everyone treats compiler warnings as errors it is certainly possible to have missed this problem. Here is some example code including an extra base class I didn't mention yet.
class Program { static void Main(string[] args) { Foo myFoo = new Foo(); myFoo.Bar(); } } internal class BaseFoo { public void Bar() { Console.WriteLine("Base Bar!!"); } } internal class Foo : BaseFoo { public void Bar() { Console.WriteLine("Bar!!"); } }
So now if I create a method called Bar without realizing there was already one on the parent class I will be hiding the parent one and breaking the existing logic. Since the old code isn't tested I will not know about it. If I had written a test before the code, I would have noticed something odd when the compiler didn't throw an error.
I think it is an interesting debate. Not very important, but interesting. Perhaps people have some more reasons why it should be one way or the other.
One analogy I like using when talking about interfaces is the car. I like it because cars have a standard "interface" and most people know how to drive cars. In a post I wrote recently about dependency injection, I mentioned the importance of programming against interfaces instead of concrete classes.
For my car analogy I will start by saying that you are the program. You have been programmed against an interface. This is a good thing. You know how to drive a car. In this case "Car" is the interface. (Remember this means a literal interface, so it could be an abstract class.) You learned to drive a car. It doesn't matter what brand make or model. Since you know how to drive a car you can drive anything that implements the car interface even if it is not a car.
When you need to get from one place to another you can use any car with the same interface you know. This is very useful. You may not know how to operate all the features (methods) of that specific car. For example do you might not know how to operate the extra parts of a tow truck, but you could still drive it.
I like that analogy for interfaces.
Notice that I said earlier that, "you can drive anything that implements the car interface even if it is not a car". So before you can get your license to drive in the United States you need to pass a test. That is kind of like testing. Well there are two ways we could test your driving.
Right now the current system used to test drivers is an integration test. Perhaps in the future we will have a nice unit test to test our drivers. I am obviously going somewhere with this, so I will get straight to the point.
The way we test drivers now is we have someone sit in the car and watch what you do. We have to have very predictable courses set up in advance. We also have trouble controlling external variables (other drivers on the road). We can't control the weather for these tests, but they will be there when you're taking the test. Observations are made by an external entity (the person testing you) one that can't always get the exact interactions being made. All of these external resources even when they're controllable make this an integration test. We are dependent on too many other things.
A unit test for testing how well someone drives would need to break the dependency on a car by using an interface. We've done that. We are saying that a person knows the "car interface". Now we need some fake car that we can use for testing purposes to remove that piece we don't control. One that records all the interactions that the driver makes with the car, so we're not dependent on external observations of what is going on. We also need to break the dependency on real roads, since traffic conditions and the environment are difficult to change, control, and standardize. What does that sound like to me? A video game or in more professional terms; a simulator. The driver can sit down with this thing which has the same interface as a car, behaves as a car, works like a car. We can give the driver any scene, environment, conditions, etc. we want. We can also accurately measure all interactions with our fake car.
Maybe some day we will actually test drivers this way. It certainly would make it faster and easier to test. We could test more often. Considering that once someone has a license we don't test them again....
Would you do that with your code? I run unit tests every time I make a small change. Integration tests every time I check in.