Softwhack

One of my favorite shortcuts in programming with C# is the null coalescing operator, better known as '??'. var something = aString ?? "somethingelse"; Is a shortcut to... var something = aString == null ? "somethingelse" : aString; However, it is important to note that it does not take care of the empty string case, which is also vital to check for... var something = string.IsNullOrEmpty(aString) ? "somethingelse" : aString; Unless you can absolutely guarantee that a string will either be null or have a value, the '??' operator then becomes useless (sadly) for strings. EDIT:  As of .NET 3.5, you cannot overload this operator, so I would not recommend using this operator with strings, unless an empty string is acceptable.

While experiencing the major headache of converting our existing web app to use LINQ to SQL instead of datasets (b/c we'll be switching to a Silverlight front-end using WCF services), I started making a list in my head of all the things I found really helped me get this conversion done as quickly as possible. Although the pain was unavoidable, it was greatly lessened by following some simple guidelines. The guidelines I have below are mix of LINQ specific guidelines, and generic data access layer guidelines. First, understand that we are a Microsoft shop, completely reliant on stored procs. With this in mind, it should be needless to say (but I'll say it anyway) that I really didn't have to/get to do too much LINQ, as in LINQ queries. The guidelines I will outline below are centered around this idea. 1. Put your entire database into one dbml. As far as I was able to determine, it is not possible to do cross-context LINQ queries. Even if you are using nothing but store