So long, and thanks for all the chips: Programming

The "var" controversy

Thu, 24 Apr 2008 14:44:48 GMT

There's some blog buzz going on right now about the appropriateness of using the new C# "var" keyword. I first ran across the meme from Jean-Paul S. Boodhoo's blog, with this post. He later linked to a post by Ilya Ryzhenkov on the same subject. One of the responses on Ilya's blog read:

"The upshot here is that vars generate some serious code - all for good reason when using LINQ. But NOT for a good reason if you’re being lazy - which is the point of this whole post. If you find yourself using “var” anywhere that’s not within a LINQ statement, it’s probably not a good idea."

This response was quoting a post by Rob Conery. Let me first say, I have not read all of Rob's post (mostly because the formatting is so bad, it makes it hard to read the post, and I don't have the time to spend on the effort). Maybe this quote is taken out of context, so take what I say next with a grain of salt. This quote is utter hogwash. The "var" keyword produces no extra code. Prove it to yourself.

public class Foo
{
}

class Program
{
    static void Main(string[] args)
    {
        Foo explicitFoo = new Foo();
        var inferredFoo = new Foo();
    }
}

The resultant IL that's generated is this.

.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 1
    .locals init (
        [0] class Playground.Foo explicitFoo,
        [1] class Playground.Foo inferredFoo)
    L_0000: nop 
    L_0001: newobj instance void Playground.Foo::.ctor()
    L_0006: stloc.0 
    L_0007: newobj instance void Playground.Foo::.ctor()
    L_000c: stloc.1 
    L_000d: ret 
}

The code for the explicitly declared variable and the inferred though "var" variable is identical. Do NOT fear using "var" because of performance concerns, as there is none.

With that out of the way, where do I fall in opinion on this subject? Well, reading the various posts in this meme, there seems to be two camps. I think both are extremes. The first extreme is the "Microsoft Camp".

“Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types.”

I simply can't agree with this extreme viewpoint. Tell me how the following code can possibly be considered less readable for others?

var inferredFoo = new Foo();

The other camp, which I'll call the Boodhoo camp, though I don't have proof that Mr. Boodhoo specifically takes this extreme point of view, believe that you should always use "var". I can't agree with that extreme either. Can anyone tell me what the type of the following declaration is?

var current = Foo.Current;

We can have arguments until we're blue in the face about how better naming would have prevented this confusion. I don't buy the argument, though. First, names aren't always under your control. Second, even with better naming it's still possible to find yourself in situations where you don't have enough type information available to you in situations like this. C# is still a strongly typed language, and knowing the exact type your dealing with is important. Relying on the IDE is a no go for me, and relying on naming isn't always possible.

So, what do I think? Out of habit, I'm still not using "var" that frequently, but I see no harm in using it for your typical "new" statements like the first example. I don't know if I'll get into the habit of doing that or not, but I see no reason to try and talk anyone out of doing so. For other declarations like the second example, unless the type is anonymous, I'd probably favor the Microsoft guideline of not using "var" here. You can probably get away with it 80% of the time and I won't care, but that other 20% is enough reason for me to not recommend getting into this habit.

Edit: From a reply to Ilya's post by "Simon" we get a list of rules much closer to what I think makes sense.

Do use var for anonymous types
Do use var for initialization from constructors (var list = new List();)
Do use var for casts (var list = (IList)list;)
Consider using var where naming implies the type of the variable (var xmlSerializer = GetXmlSerializer();)

The last bullet point is the most controversial, but I can agree with it as long as developers are consciously considering the choice. For the rest, I can see no reason to recommend not using "var" in any of those situations.

Hackety, hack... don't talk back

Wed, 19 Dec 2007 12:16:56 GMT

I've been working for some time now on implementing a framework to enable coding WPF applications that follow the Model-View-ViewModel pattern. I've found several "dark corners" of the WPF libraries where the designers have made choices that make it difficult to extend the library. For instance, the constructors on the routed event arguments are not public, making it very difficult to reroute events back into the ViewModel. It's been frustrating, but you could always understand why the design was the way it was, even if I thought it was a mistake that should be rectified in some later release.

However, I just ran into one that just astounds me. I've been trying to implement a scheme in which the ViewModel would be able to effect navigation with no knowledge of the View. It's similar in concept to the Java Struts concept where navigation information is stored in a configuration file and is initiated via keywords instead of actual knowledge of the view (if that made sense to anyone). Anyway, I had something working fairly well, and reached the point where I had to start worrying about getting "return values" back to the VieModel. This is when I discovered something interesting. When you follow the normal pattern for handling PageFunction code, like this:

class MyPayge : Page

{

// ... other stuff removed

void Navigate()

{

MyPageFunction f = new MyPageFunction();

f.Return = MyPageFunction_Return;

NavigationService.Navigate(f);

}

void MyPageFunction_Return(object sender, PageFunctionEventArgs<int> e)

{

// what ever

}

(That was done by memory and likely has several signature and syntax issues... it's for illustration only.)

Knowing how delegates work, you'd expect that the addition of the MyPageFunction_Return would cause the MyPageFunction instance to maintain a reference to the MyPage instance, keeping it alive, and that's what the method would be called on. A little experimentation, though, proved this to be wrong. The old MyPage instance is collected, a new one is created, and that's the instance the MyPageFunction_Return is called on. I have no idea how it's even possible to do that! I started to do a Google search, and that's when I discovered something interesting. Did you know the documentation for the Return event indicates you must only handle the event from a method on the calling page? If you try and handle it somewhere else, an exception will be raised! Seems to me they implemented some hack to allow the event handler to be retargeted to the new Page instance when you return (this is the default behavior, unless you assign KeepAlive="True"). This hack either required or made it easier for them to document that you must target the calling Page with any event handler. Does that sound like a hack to you, or what? Worse, it leads to many dead ends when using PageFunction. My scenario tries to handle the return event in the ViewModel, but the situation I foundusing Google was trying to encapsulate all of the functionality in a custom control, which seems like a very common thing to want to do.

I love WPF. It makes a large part of the development effort simple, while allowing you to still do amazing things with your UI. However, there's enough of these dark corners to frustrate the heck out of me.

ViewModelExtension

Tue, 04 Sep 2007 14:44:02 GMT

Dr. WPF has an interesting blog entry with a MarkupExtension that allows you to reference other objects within the object tree. It is a nice extension (there are others posted around that do similar things, see the comments on that blog entry for some others). However, what I found interesting was the specific use case scenario for which Dr. WPF is suggesting the MarkupExtension would be useful. Why? Because this use case scenario is the exact same scenario you often find yourself in when trying to use a ViewModel. You want to set the Window's (or Page or whatever is your root object) DataContext to a new instance of the ViewModel, and said ViewModel might need a reference to the Window in order to do things like specify the parent of dialogs created in ViewModelCommand handlers. Dr. WPF's ObjectReference stuff would work here, but it seems overly engineered for what we're doing here. I already had a solution that I had been using prior to his post, that I called ViewModelExtension. Using the ViewModelExtension I can solve the exact problem from his blog entry with code like the following:

<ListBox DataSource="{loc:ViewModel rss:RssFeeder}"

ItemsSource="{Binding Path=RecentPosts}" ... />

</Grid>

The code for this extension is relatively straightforward:

public class ViewModelExtension : MarkupExtension
{
   public ViewModelExtension()
   {
   }

   public ViewModelExtension(Type modelType)
   {
      type = modelType;
   }

   Type type;
   public Type ModelType
   {
      get { return type; }
      set { type = value; }
   }

   public override object ProvideValue(IServiceProvider provider)
   {
      IProvideValueTarget provideValue = provider.GetService(typeof(IProvideValueTarget)) as IProvideValueTarget;
      object target = provideValue.TargetObject;
      ConstructorInfo cons = ModelType.GetConstructor(new Type[] { target.GetType() });
      if (cons != null)
         return cons.Invoke(new object[] { target });
      cons = ModelType.GetConstructor(Type.EmptyTypes);
      if (cons != null)
         return cons.Invoke(null);
      return null;
   }
}

The general idea here is that the ViewModelExtension will instantiate an object of the type you specify. It does so by calling a constructor that takes an object of the type of the TargetObject if one exists, or the default constructor otherwise. This extension has many of the same drawbacks as the ObjectReference extension, since it isn't a binding either. It also doesn't have all of the funtionality of the ObjectReference, so it can't be used in all of the same scenarios. However, for this typical scenario it turns out to be a much simpler and cleaner solution.

I'd love to hear your thoughts on this one.

Bazaar and P4Merge

Tue, 24 Jul 2007 20:27:01 GMT

Bazaar doesn't do much for you, by default, when it comes to resolving conflicts. If a conflict occurs, the file in question will be merged with sections of text indicating the conflict. In addition, three files will be created using the original file name and appending THIS (the file before the merge), OTHER (the file being merged) and BASE (the revision THIS and OTHER have in common). With this information, it would be possible to manually correct the conflict, but this can be tedious and error prone. It's easier to use a graphical merge tool to do this. There's a great merge tool available for free called P4Merge. You could manually use P4Merge to open the respective versions of the file in order to perform the merge, but that can be a pain when there's a lot of conflicting files.

A better solution exists. There's a Bazaar plugin that adds an extmerge command. Once this plugin is installed (follow the directions in the plugin link), you need to configure it to use P4Merge.

PS> notepad $env:APPDATA\bazaar\2.0\bazaar.conf

Add a line like this.

external_merge = p4merge %b %t %o %r

Here's an explanation of the replaceable parameters, in case you want to use a different graphical merge utility.

%b	BASE file
%t	THIS file
%o	OTHER file
%r	results file, or the original file

With this all set up, when a conflict occurs, you simply do this:

PS> bzr extmerge --all
PS> bzr resolve --all

This will first run your external merge program and then tell Bazaar that the conflicts have been resolved. The "--all" option does this for all conflicting files. You could instead specify which conflicting file to operate on. Once resolved, you'll still need to commit the changes.

Technorati Tags: Programming, RCS, DRCS, Bazaar

Bazaar on a Stick

Tue, 24 Jul 2007 14:13:03 GMT

I thought I'd blog about how I'm actually using Bazaar. As I mentioned earlier, the reason for learning to use Bazaar was a need to be able to manage a set of scripts between several computers that may not have access to each other or a central server. A DRCS solution would allow me to track and manage changes to these scripts across these computers through the use of a "central" branch I'll keep on a USB memory stick. Here's how I set this up, and how I use it on a daily basis.

First, we create a new branch on the memory stick.

PS> cd g:\
PS> bzr init scripts

Now, on a central computer in each location I can create a "shared" branch.

PS> cd c:\
PS> bzr branch g:\scripts scripts

Now I can make individual branches on each machine and use them normally.

PS> net use \\machine\scripts
PS> bzr co \\machine\scripts scripts

If I make a change on one of these machines, I simply have to commit the changes, which will also commit the changes to the "shared" branch. To push these changes out to machines at this location, all I have to do is run "bzr update". To push the changes to other locations requires a little more work, though it's simple and straight forward.

PS> cd g:\scripts
PS> bzr merge c:\scripts
PS> bzr ci -m "Merged changes"

This pushes the changes onto the memory stick. Now at the other locations I can pull the changes off the stick.

PS> cd c:\scripts
PS> bzr pull

Now on individual machines at the new location I can simply "bzr update".

This isn't much different than just copying the scripts around everywhere. However, Bazaar gives me several benefits over the simple copy. First, changes are revision controlled, which is always beneficial for code! Second, because I'm committing and updating to a DRCS instead of just copying files, it's very difficult to accidentally copy over changes made in one location that I forgot to copy out everywhere else.

Technorati Tags: Programming, RCS, DRCS, Bazaar

Bazaar Terminology

Tue, 24 Jul 2007 13:40:16 GMT

I'm finding the terminology used by Bazaar to be both familiar, and confusing. In particular, there are three terms that, for the most part, have identical meanings to how the terms are used in the centralized RCS solutions I'm used to, but for which there's a slight difference that requires different thinking about them. These three terms are repository, branch and working tree.

A repository is the the storage area that contains all the history information. The difference here is one that shouldn't be shocking: there is no central repository in a DRCS solution. However, this fact does require some different thinking. A given repository may not, for instance, contain a complete history of the "project" under revision control. Why not? Because, just as an example, a repository on one machine may not have history that's in a repository on another machine that was created with a branch. This may be obvious, but the nuances of this can be subtle and surprising at first. Entirely new ways of managing a project are possible, each with their own sets of pros and cons.

A branch is a copy of a project at a point in time, where changes and commits can happen in parelel. The difference here is that in a centralized RCS solution, there's a "main branch" or "trunk" and all branches exist within the central repository. In a DRCS solution, there is no "main branch", except possibly by convention. In an RCS it's normal to do most development in the main branch. In fact, there's often a desire to not branch, since branches have a reputation of being difficult to manage and to merge. In a DRCS, however, it's not possible for multiple developers to work within a project with out branching. Every developer will have at least one branch to themselves. Because branches don't exist within a central repository, the relationship between branches is purely logical, and you may not know what branches even exist. Branching and merging are just part of daily life, and in general are not complex operations. Another point to keep in mind, at least with Bazaar, is that branches by default will have their own repository, but it's possible (and recommended) for local branches to share a repository (see the init-repo command).

A working tree is the copy of files from a specific point in time that modifications can be made to and committed. The difference here is that the files exist within the same directory as the branch, if they exist at all. It's possible to have a "treeless" branch, and in fact that's a good strategy for a shared central branch.

Keeping in mind the subtle differences in these terms is definitely helpful when learning to use a DRCS solution.

Technorati Tags: Programming, RCS, DRCS, Bazaar

Bazaar

Sat, 21 Jul 2007 13:13:35 GMT

I've been evaluating a new (for me) RCS solution, named Bazaar. I've used plenty of RCS systems in the past: PVCS, CVS, Subversion, ClearCase. All of these were centralized RCS solutions. In other words, they all relied upon a central server that acted as the main repository. This means, in order to use them, you must have access to the server. For personal use, this means setting up and maintaining a server, which isn't always a trivial task. Worse, it means the server must be accessible from everywhere that you'll need it. I'm currently sharing some script files between about 10 machines, not all of which will have easy access to a central server. This makes maintaining the scripts difficult at best. So, I went looking for a solution.

There's a new breed of RCS solutions known as DRCS, or decentralized revision control systems. These solutions don't use a central server concept at all. All of the functionality exists in locally. Changes are made, applied and tracked locally. These changes can be pushed or pulled to other locations, in order to facility typical code sharing scenarios that exist in centralized RCS solutions. A single repository can be located in a centralized location to act much as the centralized server did in those scenarios. Or you can opt to use entirely new ways of working.

In my particular case, I can version control my scripts in a repository that I can move back and forth between work and home using a memory stick. Then in those two locations I can use a local copy as a central repository for the various machines in those networks. Changes are moved back and forth between all of the various branches in a fashion that's pretty familiar to CVS or Subversion users. So far, I'm really liking this solution.

There are plenty of DRCS solutions available. The big names seem to be Git, Mercurial, Bazaar and DARCS, though there are plenty of others. I settled on Bazaar. Git is basically a Linux only solution, so it's out. DARCS is reportedly very slow, and doesn't use a familiar scripting interface. Mercurial and Bazaar are very comparable. Mercurial is reportedly faster (and speed is one complaint I have with Bazaar), but I'm impressed with the development community behind Bazaar.

Technorati Tags: Programming, RCS, DRCS, Bazaar

The importance of documentation

Thu, 21 Jun 2007 16:32:35 GMT

Fran's Bouma has an interesting post about the importance of documentation. I mostly agree with him. We developers generally hate to write documentation, and Agile processes lead us to believe that we don't need to. Our code is the documentation.

Well, I've used enough frameworks, OpenSource libraries and worked on enough unrelated large, pre-existing products that I can say with certainty that this is simply not true. Code is not documentation, nor is it enough "information" to get you by. The amount of time required to become familiar enough with a large code base to be able to just find your way around, let alone to correctly implement something inside of it, is simply huge. I think most of us have been there in our careers. You're on a new project or using some new library, and the source code is all you have. You get assigned your first defect to work on and "become familiar with the code". You have absolutely no idea where to begin to look for the cause of the defect, and have a directory full of thousands of files with millions of lines of code.

Since we've all been there, we all fall back to the same patterns to "solve" our dilemma. Out comes grep or some equivalent utility and we search for keywords we *think* will help us to find the area of the code in which to start looking. If you're monumentally lucky, this will locate a minimum of hits and you can start trying to decipher the code. Usually, though, you have to refine your search numerous times, and sometimes you'll even have to resort in asking someone else where to look, because you simply can't find anything unique to search on, and reading a million lines of code is obviously out of the question.

So, you eventually find where to look. If the code is well designed and maintained, you can probably figure things out with little effort at this point. But we all know the reality is that the code has likely grown organically and is now "spaghetti" that you have to pick apart. Always a difficult task, but worse when you're new to the code base.

Well, you pick it apart and fix your first defect. Congratulations, that just took you a factor of 10 times the amount of time it should have. But, that's to be expected, because you're new to the code. So, on to the next defect. Rinse and repeat for a month or two.

Whew. Now you're "acclimated" to the code base. You can find your way around fine, so everything's OK now, right? Nope. Now you're given more difficult defects to work on, and since you've got nothing but the code to rely on for "documentation" you have to take what you see in the code literally. The problem is, the code is specific, but not necessarily literal. There's all kinds of information "between the lines" of the code. The "why" that Fran's talked about. So, you change an algorithm in ignorance and cause a meltdown in the code. Or you "copy" a pattern from one place in the code (and no, I do not mean you copy and paste code blindly and/or fail to refactor to properly reuse code), just to discover that there's details you don't understand that applied only to that specific place in the original code.

No, code is simply a set of instructions. It's not documentation. Documentation is designed to be consumed by humans, code is designed to be consumed by a computer. Documentation has things code does not, nor can it. Like a table of contents, a forward, an overview, an index, and figures and diagrams that convey a lot of conceptual information at a glance. Documentation is understandable by team members who aren't developers, such as QA, sales and business analysts.

I can consume a large technical manual in a matter of hours. Personally, I read Petzold's latest book on WPF in roughly 2 hours, cover to cover, and retained most of the information contained in the book. What's not retained is readily re-discoverable through the table of contents, index and other structural concepts found in documentation that's not found in code. In contrast, I'm lucky if I can read through a dozen source files in an entire work day with any real "depth of knowledge" on what I read. That's not because I'm not experienced in reading code, though I will admit there are people who seem to be better at "spelunking code" than I am. It's because code doesn't convey concepts, it conveys procedures. Code isn't structured for human consumption, it's structured for machine execution.

Technorati Tags: Programming, Design

ModelView and Commands

Tue, 12 Jun 2007 20:43:27 GMT

I believe very strongly in using the Model-View-ViewModel (be sure to search the blog site and read all the related articles) design pattern when programming in WPF. You want your UI to be as "dumb" as possible. There's two reasons for this. First, we're moving towards a world where designers will be creating our UIs, so you need to find ways to remove the programming from the UI design entirely. The designer should be able to use Blend or some other design tool to first mock-up the layout, and then databind the UI to objects provided by the programmer. If you put logic in the UI directly, it complicates the process for the designer. Even the idea of letting the developer modify the codebehind after the view has been mocked up isn't enough, since this still makes it difficult for the designer to make large changes to the UI later (such as replacing a ListBox with a Combobox or other such design changes). Databinding and Commands actually allow the designer to tie controls to data and actions with no regard to the logic involved.

The other reason is for testing. Testing UIs is non-trivial at best. UI test automation software relies on simulating a user via "robot" scripts. If you've ever done this, you know that writing these scripts is non-trivial. Worse, they break with every minor UI change. This makes doing automated UI testing extremely difficult at best. However, by not putting real program logic in the UI code at all, it makes testing the full functionality of your application as easy as testing can be. A little human testing of the actual UI will then suffice.

So, after that long diatribe, let's get to the heart of what I wanted to blog about. I've been working on that MtG Binder application, and actually have an application running now that does everything that Gatherer does. Lots of design work needs to be done on it yet, since the current UI is functional but not pretty. There's also a lot of features that go beyond Gatherer that I plan to add. In other words, lots of work yet to do. But I've learned a lot about WPF development by undertaking this endeavor.

One of the things I strived to do with this application is to use the M-V-VM pattern. That's a good thing, since it allowed me to hack together a working "prototype" that's "functional but not pretty", while allowing me to easily turn it into something "elegant" with out having to touch the code. The key to this pattern, to my mind, is the VM. Anyone who's done UI work before is familiar with MVC and it's variants, such as Document-View from MFC. So there's nothing to learn about proper data modeling, and not much to learn about proper view construction. What's new with WPF (and yes, I know it's not new to Mac developers and other folks) is how databinding and Commands allow you to really put all of the user interaction logic inside the ViewModel instead of in your View. Even if you consider the ViewModel to just be the Controller from MVC (I don't think that's accurate, but you can make the argument), with older technologies you still had to put a lot of logic in the View. Not anymore. Data, data conversions, data manipulations, and basically anything involving data can now be put into a ViewModel and trivially bound to UI controls. This means complex control interactions, such as changing data displays in a panel based on the item selected in a listbox no longer needs any event logic at all. For more complex user interactions, you can use Commands to abstract away the action coupling from the actual action. A Command that submits data can be bound to the action taken from clicking a button, or to the action of losing focus on a control, all with no event handling logic needing to be coded.

My first attempt to do this, however, fell a little flat. I put the Command definition on the ViewModel, where it belongs. But when it came to implementing the CommandBindings for the command, I ran into problems. The various command delegates should logically be defined in the ViewModel as well, but I found that the XAML didn't like wiring it this way (maybe it can do it and I didn't persist in figuring out what the issue was long enough, but I wanted to get things done and not spelunk into code through Reflector). I knew John Gossman discussed doing this, so I inspected his example code. To be honest, I didn't totally like what he'd done. He abstracted out commands into a CommandModel with virtual methods you could override for the delegates on the CommandBinding. But the actions taken by the commands is almost certainly going to require knowledge of the ViewModel. I didn't want to create objects with this kind of coupling, especially when the functionality seemed to belong on the ViewModel not on a CommandModel. So, I hacked his code to turn it "inside out". Here's what I wound up with.

public class CommandModel
{
    RoutedCommand command;
    ExecutedRoutedEventHandler executedHandler;
    CanExecuteRoutedEventHandler canExecuteHandler;

    public CommandModel(ExecutedRoutedEventHandler executedHandler)
    {
        command = new RoutedCommand();
        this.executedHandler = executedHandler;
    }

    public CommandModel(ExecutedRoutedEventHandler executedHandler,
        CanExecuteRoutedEventHandler canExecuteHandler)
    {
        command = new RoutedCommand();
        this.executedHandler = executedHandler;
        this.canExecuteHandler = canExecuteHandler;
    }

    public RoutedCommand Command
    {
        get { return command; }
    }

    virtual public void OnQueryEnabled(object sender, CanExecuteRoutedEventArgs e)
    {
        if (canExecuteHandler != null)
        {
            canExecuteHandler(sender, e);
        }
        else
        {
            e.CanExecute = true;
            e.Handled = true;
        }
    }

    virtual public void OnExecute(object sender, ExecutedRoutedEventArgs e)
    {
        executedHandler(sender, e);
    }
}

This allows me to create the CommandModel within the ViewModel and tie it to event handlers within the ViewModel itself. I you want to use it in the way illustrated by Mr. Gossman, you still can, but I prefer the functionality to be in the ViewModel.

The only thing I'm left with that still feels a bit kludgy to me is the CreateCommandBinding class with the attached property used to wire up the actual CommandBinding through our CommandModel. But it works, so I'll live with it until I find a more elegant (to my eye) solution.

Technorati Tags: WPF

IronPython as a tool for learning WPF...

Wed, 06 Jun 2007 18:21:59 GMT

This isn't anything new. It's a couple of old screen casts that show using IronPython to learn WPF. If you haven't seen them, you should. IronPython turns out to be a great way to "play" with WPF, which is useful even when you're no longer a newbie. It's a shorter development cycle to test out concepts in script and then implement in your language of choice, then it is to go through the edit/compile/test cycle.

The main reason for this post, is so that I have a convenient place to find these resources again.

http://mattgriffith.net/Permalink.aspx?guid=0b9de84a-d84e-484c-b06f-8ff75ab70b9f

http://mattgriffith.net/PermaLink.aspx?guid=a1cb7215-2719-4c38-8ce3-ba7408aa69aa

Technorati Tags: IronPython, WPF

Layout Is Difficult

Mon, 04 Jun 2007 14:04:19 GMT

I've used many UI frameworks. Some of them have built in layout capabilities, and others don't. Obviously, building a complex UI, especially one that requires the capability to be resized, is much easier to do in a framework that has layout facilities. Unfortunately, even the frameworks that I've used that have very rich layout "managers", it often turns out that creating layouts is still a difficult task. And I'm not referring to the complexities of design here. No, I'm talking about actually making your layout match your design through code!

All of that was just introduction to this post, which is a rant about my current trials and tribulations using WPF. But don't take this wrong. This isn't an attempt to bash WPF, because as I said in the first paragraph, I've found every framework I've ever used to be lacking.

The trouble is that, though layout managers follow strict and rigid rules for how child controls are positioned and sized, there are two things that make using them difficult. First, the actual rules used aren't always well documented. Interactions from nested layout managers can cause scenarios that just aren't discussed in the documentation, which generally tries to give a high level description of how layout occurs, rather than explaining the algorithm in detail. Except for corner cases, though, this issue is one that experience with the framework can overcome rather quickly.

The bigger issue is that often the layout algorithms are simply incomprehensible. They don't behave the way you'd expect them to, which makes becoming familiar with the undocumented behavior difficult at best. In some cases, it seems just impossible to figure out, and you're left with "hacking" the layout to get it to behave, at least close to how you want it to behave, for specific scenarios. These hacks, however, don't lend themselves to repeated use in similar but different layout scenarios.

Here's a great example, and one that I'm struggling with in real code, and actually what brought on this rant. Let's start with a simple layout. Imagine we have some data we want to present, and just for illustrative purposes we'll say it's data about books we have in stock for resell. There's lots of data, but what we care about presenting is the title, the price and an excerpt or other lengthy text about the book. I'm not going to be too specific here, and this is all just for illustrative purposes. We want to place the title of the book on the first line, and also place the price on this line, but make it right aligned. Then, on the next line we'll place the excerpt, but we want it to wrap to multiple lines depending on the size of the page.

All of this sounds rather simple, and in fact it is rather trivial to do in WPF/XAML. Here's some example code with hard coded data to illustrate the layout.

<Page 
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <StackPanel>
    <Grid>
      <Grid.ColumnDefinitions>
        <ColumnDefinition/>
        <ColumnDefinition/>
      </Grid.ColumnDefinitions>
      <TextBlock Grid.Column="0" Text="Title Here"/>
      <TextBlock Grid.Column="1" Text="Price" TextAlignment="Right"/>
    </Grid>
    <TextBlock TextWrapping="Wrap"><![CDATA[
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas sed neque et tellus tincidunt interdum. Morbi diam eros, imperdiet at, volutpat et, vestibulum quis, sem. Curabitur eu tellus vel felis molestie malesuada. Pellentesque nec lacus. Aenean fringilla nonummy sapien. Morbi eu odio at turpis cursus tristique. Integer nec lectus sit amet turpis bibendum feugiat. Cras posuere condimentum sapien. Vivamus accumsan, lacus at bibendum vehicula, magna elit consectetuer diam, ac luctus elit diam non leo. Vestibulum lobortis augue nec nisl. Fusce viverra purus consequat lacus. Nullam elementum mattis tellus. In hac habitasse platea dictumst. Aliquam ac velit sit amet urna placerat fringilla. Fusce mattis arcu eget urna. Sed lacus. 
]]></TextBlock>
  </StackPanel>
</Page>

This works great, and out layout is easily resizable. But we don't have a single book, we have a collection of them. So we want to do this inside a ListBox (or other such ItemsControl). So, here's the same layout, but placed in our ListBox (again, I'm hard coding things for simplicity, but you'd find the same results using styles/templates and bound data).

<Page 
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <ListBox>
    <StackPanel>
      <Grid>
        <Grid.ColumnDefinitions>
          <ColumnDefinition/>
          <ColumnDefinition/>
        </Grid.ColumnDefinitions>
        <TextBlock Grid.Column="0" Text="Title Here"/>
        <TextBlock Grid.Column="1" Text="Price" TextAlignment="Right"/>
      </Grid>
      <TextBlock TextWrapping="Wrap"><![CDATA[
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas sed neque et tellus tincidunt interdum. Morbi diam eros, imperdiet at, volutpat et, vestibulum quis, sem. Curabitur eu tellus vel felis molestie malesuada. Pellentesque nec lacus. Aenean fringilla nonummy sapien. Morbi eu odio at turpis cursus tristique. Integer nec lectus sit amet turpis bibendum feugiat. Cras posuere condimentum sapien. Vivamus accumsan, lacus at bibendum vehicula, magna elit consectetuer diam, ac luctus elit diam non leo. Vestibulum lobortis augue nec nisl. Fusce viverra purus consequat lacus. Nullam elementum mattis tellus. In hac habitasse platea dictumst. Aliquam ac velit sit amet urna placerat fringilla. Fusce mattis arcu eget urna. Sed lacus. 
  ]]></TextBlock>
    </StackPanel>
  </ListBox>
</Page>

Oops. When you run this you'll find that, despite the fact we've used identical code for the layout of the data, our text excerpt now fails to wrap! This behavior is definitely not intuitive, and it makes understanding the logic employed by the layout managers very difficult to learn.

Searching the web for explanation on this, or at least for a way to achieve what we want, I find posts like this one. So, the prevailing "solution" is a hack that removes the horizontal scrollbar. This works, but I call it a hack for a reason. This only works in very specific circumstances. Even in this specific case, it has problems. Resizing the control to be too small can cause issues with the first line of data. We really want to limit the width of the Grid to prevent having it sized too small to present the title and the price. If it gets too small, we want the user to be able to scroll to see all of the data, but in order to do that we have to not disable the scrollbar, resulting in our first problem again!

I've tried other hacks, such as data binding the Width of the TextBlock to the ActualWidth of the ListBox. This almost works, though there are some resizing artifacts caused by this. In any event, that's a fairly draconian solution to what seems to me to be simply a design flaw in WPF layout logic. I obviously made the TextBlock wrap for a reason, and any panel that ignores that is, IMHO, broken.

So, now that my rant is over, are there any WPF experts that care to explain how this simple layout should be achieved?

Edit: Here's another great example of inconsistent layout behavior to illustrate my point.

Technorati Tags: WPF, XAML

Dynamic LINQ Expression Predicates

Thu, 31 May 2007 20:52:45 GMT

I searched high and low for code that explained how to create dynamic LINQ queries. Specifically, all I really needed where's a where filter. No need for sorting or grouping. Anyway, I finally ran across this wonderful article with a PredicateBuilder extension class. Works like a charm. Thanks, Joseph Albahari.

Technorati Tags: LINQ, .NET, C#

Vote for lamest new feature in C# 3.0

Wed, 16 May 2007 16:31:53 GMT

Automatic Properties.  Lame.  Very lame.

Reading comments on various blogs indicates this is the feature most people seem to be most excited about. Which is depressing. Every other language feature being added has me excited, while this one doesn't. Not at all. In fact, I doubt I'll ever use it, and any code that I find that does use it will immediately be suspect by me.

Here's some example code:

class Foo
{
	public string Bar { get; set; }
}

class Program
{
	static void Main(string[] args)
	{
		Foo foo = new Foo();
		foo.Bar = "Baz";
		Console.WriteLine(foo.Bar);
	}
}

This "saves" me from having to write this portion of the code in this way:

class Foo
{
	private string bar;
	public string Bar
	{
		get { return bar; }
		set { bar = value; }
	}
}

The problem is, I pretty much never, ever, write code like that above. This blog post suggests that the above is useful for databinding reasons. My very first thought about that is, if databinding can't handle fields (it can't), don't you think it would make more sense to "fix" databinding so that it can, rather than add this syntactic sugar for that? My second thought is, no, even that would be a mistake, and that's at least part of the reason I never have code that looks like that above.

Huh? What the heck is this crackpot talking about?

See, when databinding, I expect my UI to update in response to changes to the data model. This means INotifyPropertyChanged or other mechanisms will need to be employed any time the data changes, and you can't do that with automatic properties that expose a public setter. That leaves one minor interesting variation that I could see someone using under rare circumstances:

class Foo : INotifyPropertyChanged
{
	public string Bar { get; private set; }
	public void DoSomethingThatModifiesBar()
	{
		Bar = "Baz";
		OnPropertyChanged("Bar");
	}
	// snip code for implementing INotifyPropertyChanged
}

But that's not a very common thing, and the syntactic sugar here has saved me very little. In fact, it does make the code a little less robust when it comes to maintenance, because now every place that calls the internal setter must explicitly add code to raise the PropertyChanged event. If I hand code this instead of using an automatic property, I can put the PropertyChanged code inside the private setter and not have to worry that we'll forget to do it somewhere in the code base.

So, what if you don't plan to use the class in question in any databinding scenarios? Or, in other words, you aren't using INotifyPropertyChanged. OK, fine. But how many such properties have you ever coded that didn't do some validation or something else in the setter. Me, I can count the number of times I've written a setter that simply did "_bar = value;" on the fingers of my right hand. Simple getters, yes, simple setters, no. So, I can see using the "public get, private set" example above in some cases, such as for the Count property on a custom collection (though even there, the property is often calculated and not a simple getter). But even for this corner case, the syntactic sugar hasn't really bought me anything. Slightly less code, but code snippets achieve the same result when writing the code, and the difference in the code when reading isn't enough to make the code any clearer (in fact, I'd argue it makes it less clear). So, I see no benefit.

Maybe there's some weird corner case reason for this feature used within LINQ that makes it a useful thing to have added, but I've never seen it blogged about and I can't fathom what such a thing would be. No, I think this feature was added simply because many people have asked for such a feature. Most, through ignorance and laziness, not wanting to type as much. Those are the people who are excited about this new feature, and I they are the ones who scare me. Good design, as I tried to illustrate above, would dictate this feature would hardly ever be used, so if you're excited about the feature it means you're probably not coding with good design.

That said, there's another class of people who wanted a feature like this, and they weren't so ignorant. They've used facilities in other languages that provide syntactic sugar for defining properties that don't make it difficult to properly design them. Here's a possible variation in C# that would have been useful:

property string Bar;

This would produce a property named Bar with trivial get and set implementations. Slightly less code, but so far this doesn't illustrate the difference in the concept yet, and is doing something that, again, good design would dictate you should hardly ever actually do. So, let's show how we'd make this work as in my INotifyPropertyChanged example above:

property string Bar
{
	get;
	set
	{
		@Bar = value;
		OnPropertyChanged("Bar");
	}
}

Here's where we get some power! I can leave the parts that are trivial out (heck, I think the above should work with out the "get;" line in exactly the same way). The non-trivial parts can now be explicitly added. We need a way to access the "hidden" variable generated for us here, and I chose to use the "@" sign that's already available for specifying variable names that are keywords. This may prove to cause problems in language implementation, and if it does, just change the "@" to "$" or use some other mechanism, I don't care. The point is, for property generators to be useful in the real world, you need two features missing from C# 3.0's implementation. You need to be able to access the "hidden" field that was generated by the compiler (possibly even from places other than getter/setter code!), and you need to be able to override individual parts (get/set) of the property to make them non-trivial implementations. With out these features, I won't ever use automatic properties, and I'd question any code that did.

Update: Jomo Fisher has an article, "The Least You Need to Know about C# 3.0", where he talks about about this new feature, calling it "one of my favorite new features." My first reaction was to roll my eyes. Then I finished reading the sentence, and you know, he's actually come up with a use for this feature. It makes it "easier" to implement immutable types. Doesn't change my mind, because even this use case comes down to simply saving you a little typing, and I think code snippets are a better choice for doing that. But it's still worthy of acknowledging.