Category: Programming

Yes, this is a horrible name. If you have a better suggestion, I’m very welcome to it.

Here is the point: I want a method on Dictionary that does what Add does, but returns the dictionary instead of void. That way I can do this.

var d = (new Dictionary<string,string>()).Insert(“hi”,”mom”).Insert(“hello”,”dad”).Insert(“peace”,”sista”).Insert(“word”,”brotha”)

And yes, I know that C# 3’s initializer syntax lets me do this instead:

new Dictionary { { “hi”,”mom” }, {“hello”,”dad”}, {“peace”,”sista”}…}

BUT… that only works with a constructor. Tomorrow’s edition will show why I want a method instead of an initializer.

* I didn’t know that initializer is not a dictionary word. I love when fields (programming) extend their own words.

This one is a bit controversial because what I’m really saying is that I want to call an extension method on null and have it return true, rather than a Null Reference Exception. This violates the best practice of keeping null semantics on extension methods, but it makes my code so easy to write, so I don’t care, I wish it was there.

public static bool IsNullOrEmpty<T>(this IEnumerable<T> source)
{
  if(source ==null) return true;
  var collection = source as ICollection<T>;
  if (null != collection && collection.Count==0) return true;
  var enumerator = source.GetEnumerator();
  return enumerator.MoveNext();
}

I say that it makes my code writable because I can write what I’m thinking.

if (somedata.IsNullOrEmpty()) takeAction(); else takeOtherAction();

Yes, I know it is there as a static, but I want it as a method on IEnumerable<string>.

public static string Join(this IEnumerable<string> source, string joiner)
{
            if (source.Count() == 0)
                return "";
            return source.Aggregate((a,b) => a+ joiner + b);
}

So that when I’ve got some strings I can join them 🙂

var logmessage = people.Select(p=>p.Firstname).Join(“, “);

Too much F# rots the brain…

Ok, maybe not, but too much F# really changes your C#. I find myself wanting to |> something that isn’t really linq-able (not IEnumerable).

After talking it over with my LINQ guru – Chris Marinos – for a good name for this operation, we both agreed that PipeTo is a good name.

public static void PipeTo<T>(this T source, Action<T> action)
{
  action(source);
}

Sure, its a dead simple implementation, but it means that I can do this:

blah.Where(…).Aggregate(…).PipeTo(Console.WriteLine)

I don’t like the verbosity of a couple days ago use of Regex(). That is not to say that I don’t still find the Regex extension method useful, but if I’m just matching I should say so.

var re = @“\d+-\d+-\d+-\d+”.Regex();
var match = re.Match(“things 10-12-5-1”);
//do things with match
var othermatch = re.Match(“stuff 1-6-8-9”);

Regex extension method is great. But for a Boolean statement I should be able to just say “RegexIsMatch?”

if ( someText.RegexIsMatch(@”\d+\.\d+”) ) …

Sometimes when dealing with lots of strings or parsing text, I don’t always want to turn directly to regular expressions. I might want to just say “if this thing has a digit”.

public static bool ContainsDigit(this string source) {
  return @"\d".Regex().IsMatch(source);
}

This uses yesterday’s Regex() extension method on string and simply returns true or false, exactly as it reads.

string field1 = GetFieldFromSomeParserOrSomething();
if (field1.ContainsDigit()) …

I don’t want to have to pull in System.Text.RegularExpression every time I want a new Regex. Perl, boo, awk and javascript just say // for regex. In C#, I can just say “abc\d{3}”.Regex().

public static System.Text.RegularExpressions.Regex Regex(this string source)
{
  return new System.Text.RegularExpressions.Regex(source);
}

Now I can write:

if (“there are (\d+) lights”.Regex().Match().Groups[1].Value > 0) …