Everything is a class!

It is amazing how often I need to remind my friends with programming doubts that C# is object-oriented - there is no line of code in C# without a reference to a class or an object. There is a class for almost everything in the .NET Framework and its interoperability features make it the platform of choice for Windows applications.

And C# is just the right language for .NET. Although people have tried to convince me that VB.NET is also completely object-oriented, it just does not seem to be a true programmer's language of choice. Never mind the syntax, the lack of braces and the presence of keywords like My.Computer (!) make it simply an uncomfortable language to work with especially for a programmer with C background.

Coming back to my friends, I had a friend calling me yesterday with a DataGridView problem. He said he had a form (say Form1) on which if the user clicked a button, the DataGridView should display all the relevant data. The guy had made the button-click event handler to invoke a method from another class (say Class1) which is fine as he meant to segregate the UI classes from the database classes. The problems are here

• The method initialized and filled a DataGridView which was a property of Class1.
• The method returned void.
• The method was called in the button-click event handler from an instance of Class1.

His code would look like

class Form1
{
......
...
private void Button1_Click(object sender, RoutedEventArgs e)
{
   Class1 obj = new Class1();
   obj.FillMyGridView();
}
.....
}
// The following class in another file, in another namespace
class Class1
{
......
...
public DataGridView Grid{ get; set;}

public void FillMyGridView()
{
   Grid = // initialize and fill Grid
}
}

Now whether you are laughing at the guy already or empathizing with him depends on which level programmer you are. I told him that a void-returning method just won't do. Although I fairly convinced him why, he was just reluctant to make a method that returned a DataGridView or a even a DataBindingSource to the form.
Nevertheless, he had a keenness to learn and that is what, I feel, any programmer should have. Never be ashamed of what you do not know - there is always more to know no matter how much you already know and there is always a guy who knows less than you do.

All is fair in love and var

The var keyword in C# 3.0 has been the subject of much scorn recently, which I feel is uncalled for. It is really a matter of personal preference - I use the var keyword in LINQ queries, and I think there's no other good way of storing the output of a LINQ query. Implicit typing is just an equally strong typing convention as explicit typing as the compiler determines the actual type, never so wrongly.

Anonymous types are, to me, a blessing of LINQ, and there's no better way to save variables of anonymous types than in a var. Using the var keyword in any context other than LINQ, however, would be undesirable, as readability can be compromised and the code would unnecessarily be cluttered.