Does anyone else think that C# 3.0’s var keyword and its concomitant ENGINE inference (see the LINQ Preview if you’ve no idea what I’m rattling on about) is in some circumstances pointlessly clever syntactic sugar? Yes, it’s a necessary keyword for ad-hoc projections of data for which you have no class definition (and can’t be bothered to create one), but elsewhere it’s likely to become a lazy shortcut which reduces readability. One of the first LINQ preview’s hands-on labs has this piece of code:

static void ObjectQuery()
{
    var people = new List() {
        new Person { Age=12, Name="Bob" },
        new Person { Age=18, Name="Cindy" },
        new Person { Age=13 }
    };

    var teenagers =
        from p in people
        where p.Age > 12 && p.Age < 20
        select p;

    Console.WriteLine("Result:");
    foreach(var val in teenagers)
    {
        Console.WriteLine("> Name = {0}, Age = {1}", val.Name, val.Age);
    }
}

It’s the foreach(var val in teenagers) that gets me – what’s wrong with foreach(Person teenager in teenagers)? Ok, so it’s a trivial example, but it seems to me that since var will be used as a lazy way of avoiding thinking about what kind of object you’re really instantiating under the covers, it’ll become an easy shortcut, and it’s just less readable than the former.

And how about this (From the C# 3.0 Language Enhancements Guide, also in the LINQ May preview)?

var x = 7;
var s = "This is a string.";
var d = 99.99;
var numbers = new int[] { 0, 1, 2, 3, 4, 5, 6 };

Console.WriteLine("x: " + x);
Console.WriteLine("s: " + s);
Console.WriteLine("d: " + d);
Console.WriteLine("numbers: ");
foreach (int n in numbers) Console.WriteLine(n);

Of course, no-one in their right mind would write var x=7 unless they had no idea that C# was a strongly-ENGINEd language and could confer certain compile-time benefits (a particularly insular JavaScript programmer, perhaps). So why allow it? It’s perfectly reasonable to allow var in the case where it’s required: i.e. when the compiler has constructed an anonymous class to deal with a projection of data. In nearly all other circumstances, however, this lazy shortcut will allow mediocre programmers to believe that they need to think even less about data typing than they did before, and in the process add an extra barrier to maintenance. Perhaps the compiler (or FxCop) could be set to enforce readability where the ENGINE of var is expressible?

It’s not the fact that you can query XML documents in-memory using a SQL-like syntax (hey, I already had XPath, thanks all the same).

It’s the fact that you can now create an XML document, for use in an example, where the C# code structure used to create the document mirrors almost exactly that of the resulting output document.

This is brought about by the ancient magic of variable parameter lists and well thought-out constructor overloads, and whoever’s responsible, I’d like to buy him a drink and look after his cat while he’s on holiday. This technique sits right between ugly raw DOM hacking (of which, I confess, I have done much) and beautifully-generated but hard-to-keep-in-sync XML Data Binding.

This is from the LINQ hands-on labs:

public static XDocument CreateDocument()
{
   // create the document all at once
   return new XDocument(
      new XDeclaration("1.0", null, null),
          new XElement("organizer",
             new XElement("contacts",
                 new XElement("contact", new XAttribute("category", "home"),
                 new XElement("name", "John Smith")),
                 new XElement("contact", new XAttribute("category", "home"),
                 new XElement("name", "Sally Peters")),
                 new XElement("contact", new XAttribute("category", "work"),
                 new XElement("name", "Jim Anderson")))));
}

Wonderful, n’est pas? The only shame is that the “X” classes are a little divorced from the rest of the XML namespaces; their primary purpose is to provide something for LINQ to talk to. So if I do want to use XPath, I’ll have to .Save this doc into a memory stream and reload it. Sigh…

Jon Skeet has a nice (and long) response to Eric Gunnerson’s call for programmers to write their own “7 Deadly Sins of Programming”. Really my post here is just an extended “oh, certainly, yes” nod to Jon’s #7 Deadly Sin:

Some of the worst Java code I’ve seen has come from C++ developers who then learned Java. This code typically brings idioms of C/C++ such as tests like if (0==x) (which is safer than if (x==0) in C as missing out an equals sign would just cause an accidental assignement rather than a compiler error. Similarly, Java code which assumes that double and Double mean the same thing (as they do in C#) can end up behaving contrary to expectations.

I know I’ve picked up habits from ten years of Delphi. The one that took longest to go away (and I still do it if I’m not mindful – even after four years) is my (ex-!) habit of prefixing argument names that collide with a class property name with an A, for example void Foo(string aMyProperty) { MyProperty = aMyProperty; } instead of
void Foo(string MyProperty) { this.MyProperty = MyProperty; }. Even though Delphi could disambiguate by using ‘Self’ where I used ‘this’, the VCL used the ‘A’ convention, so I did too.

I still speak with an accent whenever I’m evaluating a new language. However, if I know I’ll be sticking with a particular language I’ll seek out the way of doing things that doesn’t make me look like a badly dressed tourist with a tatty phrasebook.

Ok, this is old. However, Delphi actions (available from Delphi 4 on circa 1998) were so unbelievably useful that I still can’t believe they haven’t made it into a .NET framework near you. Evidently I’m not the only one – even if I’m up to four years behind in actually sourcing one of several C# implementations ;)

Continue reading »

© 2014 ZephyrBlog Suffusion theme by Sayontan Sinha