In my travels around .Net land, I've come to know, love and exploit several denizens of the tribe of C#. Some of these have already been written about, such as Yield return and the => operator. But more recently, I've had the opportunity to educate some fellow travelers on two of the most useful, but least used operator. Those being the Comparison Operator (?:) and the Null Coalescing Operator (??).
Lets start our adventure by watching the Comparison Operator in it's natural environment. If you watch closely, it'll show you it's syntax...
bool statement ? true : false
Due to it's nature, this operator is sometimes called the Ternary operator. The reason being is that it takes 3 operands. In normal use, here is what it looks like:
CurrentBeer.Empty==True ? CurrentBeer = Wife.GetMebeer() : Me.TakeDrink(CurrentBeer);
(this can be shortened further by taking out the ==True, since .Empty is most likely a bool property)
CurrentBeer.Empty?CurrentBeer=Wife.GetMeBeer():Me.TakeDrink(CurrentBeer);
You can see how this replaces the overly verbose syntax of :
If(CurrentBeer.Empty)
CurrentBeer = Wife.GetMeBeer();
else
Me.TakeDrink(CurrentBeer);
Syntax sugar? Maybe. But it's definitely useful as a quick way to get things done. Elegant, Efficient and Desirable, three features my first girlfriend was lacking in.
But wait! Theres more! Just send me three easy payments of $29.95!
So now, lets check out the ?? operator.
The ?? operator has saved me boat loads of finger_impact_on_keyboard stress ever since the advent of C# 2.0. It's easiest to think of this operator working similar to the comparison operator above. Lets lift it's skirt real quick and have a peek at how it functions
x = ValueThatMightBeNull ?? DifferentValue;
Ok, much like the first time you played doctor, things might be confusing, but it's really simple. Basically the ?? will evaluate whether or not the thing to the left of it is null, if it is, it will evaluate and return the thing on the right. Lets just see it in action, it's easier that way...<Dear "Usually offended by my posts": Please Insert vulgar joke of your choice here>
//This is how my wife found me
Mate SuitableMate = Mate.Get(GoodLooking)??
Mate.Get(AverageLooking)??
Mate.Get(DoesntHaveAnAssForAFace)??
Mate.Get(AtleastHeHasAJob)??
Mate.Get(Dave)
If your confused, let me lighten things up for you hear. Each A = B??C statement is the equivalent of saying
If(B != null)
A = B;
else
A = C;
So when we string them together like that, it's just like saying If = null else if = null else if = null etc etc etc... So, obviously, based on our previous statement, everything up to Mate.Get(Dave) must have returned null if my wife wound up with me. I do have a job now though....so I wonder if i still would have made the cut.
There is one more benefit of using the ?? operator that I actually stumbled across. Take this code as an example:
public class DataObject
{
public NullableObject a = 1... etc
}
public class BO
{
public NullableObject Stinks= 0;
public static implicit operator BO(DataObject e)
{
return new DataObject{Stinks= e.a};
}
}
now...later on in the UI of the app (which should NOT have ANY reference to the DataObject class) if we write this code:
If(MyBo==null){Console.WriteLine("WOO HOO, You have no BO!!");}
..were going to get a compiler error. The reason being, as far as I understand (hopefully commenter's can expand on this) is that when you compile that statement, the compiler is doing type checking against the objects used in the class your checking for null in. In other words it checks to see if anything is returning null from within the class. Now, since the operator takes a type of DataObject, the complier expect you to have a reference to that class...if you don't, then *Poof* no compile.
Now, to get around this, we can write...
SomeoneElsesBo = MyBo??(MyBo = new BO());
....And the compiler is happy.
Hell, we can even put these two operators together, check this out:
Mate SuitableMate;
Step Next_Step_In_Life = ((SuitableMate = Mate.Get(GoodLooking)??
Mate.Get(AverageLooking)??
Mate.Get(DoesntHaveAnAssForAFace)??
Mate.Get(AtleastHeHasAJob)??
Mate.Get(Dave)) == Dave?SobQuietly():null)??(Step)PartyItUpWOOT();
I'll leave you with this. The best places I've found to use the ?? operator is in returning data base fields where the value might be null, here is a quick example and the best way I've found to implement the ?? solution
//First i check to see if the value from the db is DBNull.value
//Dr = DataReader
//Do = Data Object with nullable Types
DO.ValX == DBNull.Value?null:(Int32?)dr[0]
//If you don't get the ? reference after the Int32, no worries, It's a nullable type, and I'll post about it soon.
The reason I do this, is so I can keep the actual DB value in my DataObject, which is supposed to be a true reflection of my data. Later on, in the actual business object, where I don't accept Nullable types I can say this.
BO.ActualValX = DO.ValX??-1;
And Bada-Bing, I'm good to go. Later on, i can pass either -1 or even null back into the DB and repeat this cycle when retrieving my data, it works, and i don't have any logic, other than conversions from DBNull, in my Data Object class.
We've all heard the buzz acronym TDD. But has anyone actually put these things to use in a practical way? I know of a couple of guys who have, but for the most part, a majority of developers tend to shy away from this new fangled gadgetry. The main reason, I believe, is that it can be difficult to justify a learning curve when:
- A solution in a current ver. of code exists
- Management is on your ass to just "Get it done"
- Open source projects are a natural contraceptive
Now that I've stated the obvious, lets get on with it.
Requirements, everyone gets them, no one knows how to write them and they are usually so vague that you can tell someone has a huge ass their trying to cover. The biggest pains when it comes to requirements are, the acceptance of a "Moving Target" as part of business, and flaky UI designs in the document. Honestly, does Barbara, the manager of the mail room, really know what the hell a number spinner is or is she just a control freak who needs a coke and a bottle of horse ex-lax to work that stick out?
To put it bluntly, Requirements define the business logic that needs to go into the app. They are not justification for the app, that should have been done long ago. Neither are they "Screens" or "Mockups". Those get done by someone who actually (supposedly) knows what their doing. That may be you, it may not, depends on your shop. Either way, they don't belong in the document.
So, what do these obvious statements have to do with TDD?
Lets start at the top. Typically, in non-TDD terms, when you get the requirements, you start coding. Sure, you look at whats needed, pick out the sticky algorithms and look for logical objects, but ultimately, the first thing you write is:
Namespace Giveme
{
public class Beer
{
public int AndWomen()
{
Your mileage may vary, but typically you start writing code intended for production right away. And when the boss man speaks, you refactor refactor refactor. What happens after several refactors? Well, for one you've lost an easy way to CYA because none of your code matches the original requirements, it all matches what Boss man said. So now your left, holding the bag while Barbara and the Boss man say "We did our part, the developer is taking to long". At this point you get the "Talk" from someone who has no clue what it is you do, but by god, they know how to manage!
Enter TDD. It may not cover your ass completely, but it 
may slightly, depends on how big an ass you are. Plus, you'll get your work done a whole lot faster. I know what your thinking...that writing unit tests is as painful as sitting the wrong way on a pineapple (is there a right way?), and it can be. Typically we've been introduced to unit tests by means of testing after development, which goes something like this
Manager: TDD is shiny. Bob, go write unit tests for all our legacy code
Bob: OK, but that will take me several months to complete
Manager: Nonsense, your just making sure working code works, Now, Kiss the ring and get me a pineapple. Then I expect 150% code coverage by tonight!
So Bob goes off and attempts to generate unit tests around the existing code. The existing code has some pretty complex methods which must be refactored out in order to test, so more tests are written. Come to find out the refactored methods need to be refactored again, and again and again....and new objects must be created. This cycle can (and in most cases does) create unstable code. This is what makes developers climb the bell tower, or have the sudden urge to become postmen (if you didn't get that last joke, just move along).
OK, so say your starting a new project. You've learned that unit testing after the fact leads to A LOT of re-factoring, and is a code destroying monster. So you want to avoid that at all costs. The solution? Write your tests first, get them out of the way. The simplest form of TDD is:
- Write Test
- Fail Test
- Write Code to pass test
- Pass test
- Refactor to nice code
- Go To : 1
Otherwise known as
1.) Red
2.) Green
3.) Refactor
So here is how it helps you. (I'm diggin' the numbered lists today)
1.) Unit Tests are tied to the requirements
2.) Writing tests first ensure you write ONLY the functionality you need
3.) 1 + 2 = quickly written solid code .
Here's how it works. First off, before writing any code for production at all, you break down your requirements into subsections, and then break those down. so on and so forth. Once your at the smallest bit of requirement (determining how much beer it would take for individual A to take individual B home in this instance), then you write a unit test that specifies how your method will act and look from the outside:
public void BeerGogglesTest()
{
//We really should atleast have a container class
BarFlys bf = new BarFlys();
//What we expect the method to return given the inputs
double expectedValue = 20;
//Test constants
//We'll talk about the whole "Mock" thing in a second.
int Dave= new MockPersonDave();
int DavesWife=new MockPersonDavesWife();
double BeersAlacContent = 7.5;
//Here we check
double HowManyBeers = bf.NumberOfBeers(BeersAlacContent, DavesWifes,Dave)
//Here we assert the value we received was the value we expected
Assert.IsEqual(expectedValue,HowManyBeers);
}
So...now you compile that. Yes, before writing any more code. Of course the test fails with a few exceptions. Your first task, get rid of those exceptions. With TDD, your essentially coding to your implementation, or API. Similar to coding to an interface. So every bit of your application comes down to ,"Write enough code, just barley enough, to legitimately pass the test"(notice i said Legitimately, so all you smart asses who would return 20 every time need a lesson pineapple-fu). In our scenario above, we would need to implement a public BarFlys class with one and only one method. That method would only take the 3 parameters listed. Don't worry about extensibility or any fancy OOP crap yet. That will come in time....maybe.
public class BarFlys
{
public double NumberOfBeers(double AlacConsistancy, IPerson p1, IPerson p2)
{
double p1DesireToLeave = CalculateDesire(p1.InitialInhibition,p1.alacholConsumed,p1.tolorance);
double p2DesireToLeave = CalculateDesire(p2.InitialInhibition,p2.alacholConsumed,p2.tolorance);
return Math.Sqrt((p2.CalculateDesireAbility(p1) + p2.DesireToLeave)/p2.tolorance)*p2.CommonSense
}
}
As an important aside, we must have already written tests for CalculateDesire in order for this to be a valid test run. We'd want to test it in the same manner we are testing "NumberOfBeers." If we didn't test those method first, then we may end up skewing our test results if there is a failure in one or both of them. Meaning NumberOfBeers would fail, but only because a Dependant method failed.
Once you pass that test, you move onto the next test. And continue on until you have a nice little set of tight, solid code. After wards, you begin to refactor. But, at this point, refactoring isn't about design changes. Your design has already been defined by your tests. Instead, you can focus on the real things, like optimizations and readability.
So, what are these "Mock Objects" I was going on about earlier? Well, Mocks can warrant their own blog post 
in- and-of themselves. But here are the essentials. A mock object works just like a bottle of O'Dules or Coors Light, it's a fake implementation of a real solid object. Take this for example: You need to develop the front end to a website that runs exclusively off of web services. However, like most developers, the guy working on the services was hit by a bus or married a super model (your choice, i for one vote bus, that still leaves me the opportunity to meet this super model turned on by developers).
Management has threatened to stop paying you if you don't get off your ass and start writing that front end. The Solution? "Mock" the web services. Essentially, your going to write an object that mimics the behavior and implements the interface of what the web services are supposed to look like. Your also going to have those mock objects return data in the same format that the web services would.
Now, granted, it didn't take that many beers when I first met my wife. However, I think her common sense had some environmental issues to contend with, like she just saw dirty dancing or some other chick flick. Either way, I beat the odds :)