Code Generation Is Bad, M’kay?

Code generation: problem solver.

Composition, abstraction, design patterns, a walk in the park thinking of a better solution: constructive techniques.

It often tempts me to use code generation when I’m facing a problem that requires a lot of code to be written in order to solve each of it’s instances (ex: classes in the data access layer). It is the case when I’ve already used all the tools in my (small) development arsenal, and it seems I can no longer simplify and reduce the code that needs to be written by the clients of the solution. The clients being, in most cases, myself.

And the most annoying thing is that I feel there is still too much repetitive code or logic, and there must be a better way around it. But the programming language doesn’t want to help me anymore, and I can’t think of any other solution. And I try to scribble other designs, and when I think I’m onto something, and try to translate the new solution into code, there is always a catch, some missing feature of the framework library, or of the language itself, or a glitch in my logic.

And there’s the Code Generator behind me, grinning, telling me: “You know you can’t avoid me…”. But I keep on trying: “Go away, leave me alone, there must be a better solution to all this crap (that I’m mostly to blame for)!”. And he goes: “Don’t ignore me, I might be your best friend at the moment.” - “But I hate you! You are possessive, you give my code inertia, and I suffer headaches when I try to make even the smallest change.” - “Hmm, that’s an oxymoron: the best friend you hate the most. C’mon, see the bright side, your code will barely change. It will look as young as when you first wrote it, even after years of use and abuse. It will become immortal :).”

Finally I give up and I try to make up for the compromise I’m committing: “At least I will generate very beautiful code, with all the comments it needs and exception handling and bells and whistles. And there will be extension points, so I will be able to add more features to the definition, like automatic validation-based-on-some-obscure-rules-that-I-will-come–up-with…”. And I feel sad…

Well, I can’t be sad about my work. I’m still a programmer because I like programming, and I expect that software development should bring me joy and fulfillment, not frustration and sorrow. That’s the moment I start to think that if my system was built the right way, every feature should be replaceable. I don’t have to bang my head into finding a perfect solution for a functionality, that will probably be replaced in the future.

Ok, so what I really need to take care of is that the generated code is isolated enough so other parts of the system don’t have direct dependency on it, but rather on a contract the generated code implements. Maybe a smarter person will find a solution for my problem, and they usually do. At that time I’ll be able to end my unpleasant relation with the code generator, and look behind and smile.

Resources

http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell

The Evils of Shared Check Out

I won’t discuss the obvious what-do-you-do-when-somebody-else-checked-in-before-you-and-now-you’ve-ended-up-resolving-the-conflicts. I think there are more subtle motives why the version control shared check out has negative impact on modern software development.

I believe that the shared check out feature of most source control system (svn, cvs, tfs) originated in a time when developers worked on huge code files, when solving one bug meant making adjustments in more than one of these monstrosities at the same moment. In a time of stone age development tools, when modern programming concepts like OOP and FP were in still in the realm of academia and of obscure languages.

The tools and languages evolved, but the way they were used had its own inertia, based on human habit and familiarity with a way of “doing things”. Forget about one class - one concern, some people are still struggling with one function – one concern.

The conclusion is that if you are aware of a couple of development techniques, there will be no need for shared check out. One class should be modified for only one reason, so two people don’t have to edit it at the same time.

Of course there are counter examples. I already hear people shouting “configuration files”, “generated code files” etc. Those are exceptions and at the same time, they are not. If you’re willing to break the structure into small, manageable parts, you’ll find a solution for them. And if you really need to store many things into one file, be sure to set rules for how people should edit it, so they know how to not get into trouble. This is a similar problem to using only pure functional programming. FP is great, but you’ll need to modify state sometime: make sure you’re doing it in a standard, isolated way, so when a problem arises you’ll know what you’re dealing with.

Why You Should Write Your Own O/R Mapper ... Or At Least Try

Because you will not use it. But in the process you'll probably learn a lot of things about what a data access layer is. And more important, you'll be able to judge the existing O/R mappers and chose the one that fits most of your needs.

The down side is that the period of time before you choose to "upgrade" to an already existing solution will seem a waste, and all the code you've written must be thrown away. That won't be an issue if you keep in mind that things are replaceable and if you build a loosely coupled designed so components, like the data access layer, can be replaced, almost, effortless.

This pattern applies to other general "patterns", like dependency injection containers. Hands on experience with their "entrails" should give you a better understanding of how they work, and a better appreciation of the ones that are already available. And chances are you've already tried to build something similar but never knew exactly what you wanted, or what the big picture of the solution is.

Nice Design Example for a Simple Data Access Layer

If you are in the process of implementing a small data centric application, you'll probably need to write some data access code. I've recently stumbled upon Los Techies, which is a wonderful resource for good programming practices. I especially enjoyed Jimmy Bogard's series on the problem of separation of concerns.

The series is centered towards refactoring an existing solution to a better design, employing well known patterns and practices. But the interesting part is that at the end the result is a nice blue print for a general data access layer based on Linq. And a really good start point if you're trying to build one.

Below are links for the six parts of the series:
Separation of Concerns - how not to do it
Separation of Concerns by example: Part 1
Separation of Concerns by example: Part 2
Separation of Concerns by example: Part 3
Separation of Concerns by example: Part 4
Separation of Concerns by example: Part 5

Linq to SQL Server CE and uniqueidentifier columns

There will be a couple of issues if you you try to use linq to sql with a SQL Server CE database. First of all the VS2008 designer doesn't allow adding tables from this type of database. The solution is to use the SqlMetal command line tool in order to generate the dbml or the code file (see here).

The second issue is that uniqueidentifier columns with the rowguid property will not work. More precisely, they will not autogenerate a value upon inserting a new row. Setting the column property to IsDbGenerated in the dbml mapping file is even worst: it will crash the insert operation. There is a workaround for this problem: in the partial class of the respective table entity, create the partial method "OnCreate" and manually set a new Guid for the new record:

partial void OnCreated()
{
    if (ID == Guid.Empty) ID = Guid.NewGuid();
}

Implementing a Double Linked List in C# - part III

Welcome to the third part of the series on implementing a double linked list. It is now time to finalize the basic functions of the list, as well as some extra helper functions. The latter have the purpose of easing the use of the list for its users.

In this episode we'll cover the following:

• Delegate some of the concerns of the list to its nodes;
  
• Implement the IEnumerable interface, and the associate iterator;
  
• Add a bit of "closure" to our list.
  
• Removing items from the list
  

Preamble

The main difference between our implementation of the doubly linked list and the one provided by the .Net framework, is in the accessibility of data. While the .Net framework version exposes the data through the nodes containing it, we, on the other hand, expose it directly. This might be a shortcoming in terms of flexibility for navigating locally in the list. But the benefits come in form of structural integrity of the list, while permitting low level alteration of the structure of the list, and a better user experience in terms of accessing the data. What I mean by keeping control over the structural integrity of the list is that the consumer of the list can't make modifications that could break the chain of references or desynchronize the count of nodes, but the list can make modifications at that level internally. Of course these low level operations are also available to the inheritors of the list.

Revisiting the Node Class

Until now we've managed to ignore the Node class, but she "feels" that and tells us: "Listen, I'm pretty good at holding hands (references) with my left and right neighbors, so let me add new neighbor nodes as well as remove myself from the list". So we delegate to the Node class the concern of "keeping up references" during the operation of the list.

Adding a neighbor to the left of a node, means that we have to change:

• the reference of the original left node to its right node, to the new node;
  
• the reference to the original left node, to the new node;
  
• the reference of the new node's left node, to the original left node;
  
• the reference of the new node's right node to the current node.
  

  public Node<T> EnchainBefore(T item)
  

  {
  

       Node<T> node = new Node<T>();
  

       node.Data = item;
  

       node.Previous = Previous;
  

       node.Next = this;
  

       Previous.Next = node;
  

       Previous = node;
  

       return node;
  

  }

  
  

Removing the current node means we have to make its two neighbors reference each other:

public void RemoveFromChain()

{

     Previous.Next = Next;

     Next.Previous = Previous;

}

Implementing the IEnumberable Interface

The interesting part is not implementing the IEnumerable interface, but the IEnumerator. The twist is that the enumerator must "enumerate" through the list in two directions: forward as well as backward. Essentially the iterator will follow the chain of references starting with the left sentinel and ending with the right sentinel for forward enumerating. The iterator will go the other way around for backward iteration. This logic is embodied into the MoveNext method:

public bool MoveNext()

{

     if (forwardDirection)

     {

          current = current.Next;

          return current != rightSentinel;

     }

     current = current.Previous;

     return current != leftSentinel;

}

The rest of the code is just plumbing and we shall not go over it.

A Little Bit of Closure

We need a way of applying some function to the list of nodes. The process must be controled by the function, meaning that the function can dictate when to stop the process.

Introducing the predicate. The predicate is a delegate with one generic parameter, which returns a boolean value. We could have built our own delegate, and in one way it would have been better, because we are abusing the purpose of the predicate as intended by its creators. But why reinvent the wheel when it's already there.

So let's define the Apply method, which applies a predicate received as parameter to each node, as long as the predicate evaluates to (returns) true and there are still items in the list:

Public virtual void Apply(Predicate<T> predicate)

{

     Node<T> node = leftSentinel.Next;

     while (node != rightSentinel && predicate(node.Data))

          node = node.Next;

}

Removing items from the list can be easily implemented by using the Apply method. What I intend to do is iterate through the list as long as the current node does not contain the value we are trying to remove, and when we find it we'll ask the containing node to remove itself from the list and stop the iteration:

Apply(delegate(Node<T> node)

{

     if (item.Equals(node.Data))

     {

          node.RemoveFromChain();

          count--;

          return false;

     }

     return true;

});

Another method that coud use the help of the predicate is the Add method. This way we could make the items beig added to the list obey certain rules:

public virtual void Add(T item, Predicate<T> check)

{

     Node<T> node = leftSentinel.Next;

     while (node != rightSentinel && !check(node.Data))

          node = node.Next;

     AddBefore(node, item);

}

Now we have to tools to implement an ordered list:

public class SortedList : DoubleLinkedList<int>

{

     public override void Add(int item)

     {

          Add(item, delegate (int data)

          {

               return data < item;

          });

     }

}

That's all for this episode. Remember you can find the source code here.

Creating a Double Linked List in C# - Intermezzo

Day by day I am amazed by Google's other services, besides web searching. One of the useful collaboration services offered by Google is Google Code. It is a free service for project hosting, which provides SVN version control.

You can now find the source code for the double linked list series at this location.