Attributes and Declarative Programming

The Death of Traditional Compiler Directives

by William Ryan

Since I've been a programmer and learned how to use the things, I never liked  Complier Directives.  Ever since I first encountered them, I thought they were ugly and there was nothing Object Oriented about them.  Before I even knew what Declarative Programming was, I was yearning for it.  I'll be the first to admit that Compiler Directives were a necessary evil in the past, emphasis on the evil part.  

Anyway, in comes .NET and there are these really cool things called Attributes that fix so much of what was broken in the programming world.  Creating Custom Attributes is a discussion unto itself (one I probably need to write about soon) but let me run through why I like them so much.

In the old days of ugly compiler directives you would mark code with Conditional statements and then define build constants.  When the code was compiled, the preprocessor directives indicated what would be executed and what wouldn't be.  Syntactically, they were clunky often looking like this:

#If Not Something Then #End If

The problem is that code would often be littered with these things, and they quickly become a crutch.  Then little by little many projects suffered from Conditional Creep, where many Conditionals were added (I've personally worked on a project where there were over 10 of them in just one .dll.  You'd have to remember what they all were, remember when to set them and then verify that they were all set correctly.  Forgetting one of them could cause major problems.  Now, this was a lot better than keeping seperate code bases for different clients that had essentially the same program, or test/release builds, but it was still ugly.  Then in the code, they'd be all over the place.  Trying to debug this stuff was a nightmare because you first had to know what they all were, then what they meant, then where they were located.  You could use Find/Replace and other mechanisms, but there was no way around the fact that it was an ugly solution.  After all, aren't we supposed to be writing Object Oriented Code?  What is Object Oriented about PreProcessor directives?  Shouldn't I be able to set my Object's state and know what state my object is in when the program first runs, and respond accordingly?  Moreover, what if I want one object, or method/property of an object to resopnd to multiple possible conditions?  With many objects we define flags so we can set multiple properties of our object, and we've had this ability for years.   Why should it be different with compilation?  Lets say that I wanted my object to respond to the fact that the build is Release or Debug, that it's version is X or Y, that's it's being used InHouse or Distribution, and being deployed in NorthAmerica, SouthAmerica, Canada or Asia.  We'd set all of those preprocessor directives and away we'd go right?  Wrong.  Imagine what it would look like to have all of those Conditionals defined. And what takes precedence over what?  For instance, What if we went with the first of each of the choices on weekdays, but went with the second of the choices on Weekend builds.  (Obviously this part isn't realistic, but I want to make a point).  What would the branching look like?  What would come first in the IF Block?  And would you really want to write or read the code with all of this nested If logic?  The obvious answer is a resounding NO!

So how does .NET change any of this?  Let me walk through a really simple example.  Let's say that we have a project and if it's a Debug Build we want to use call the InitializeConnection method of our ConnectionManager class which points to our test database, otherwise we want to point to our production database. This is a pretty typical use of preprocessor directives so I think it will illustrate the point well.  Using Attributes, our code might look something like this:

public class ConnectionManager {    private string DebugConnectString = "blah blah blah; testdatabase; blah blah ";    private string ReleaseConnectString = "blah blah blah; Releasedatabase; blah blah ";    private SqlConnection cn;     [Conditional("DEBUG")]    private void SetConnectionDebug()    {        cn.ConnectionString = DebugConnectString;    }    private void SetConnectionRelease()    {        cn.ConnectionString = ReleaseConnectString;        }    public ConnectionManager()    {         //Create a new Instance of cn, but without      //an initialized ConnectionString       cn = new SqlConnection();       //If built in release this is the only one that will be set      //(The ConnectString pointing to Production even though      //we are calling SetConnectionDebug right afterware -      //it's because SetConnectionDebug will never execute       SetConnectionRelease();       //This one will reset the connection string to the Debug      //Database if that attribute is defined       SetConnectionDebug();                     } }

Now, by adopting a naming scheme, it's very clear what we are doing, and only one of these two scenarios can be true.  All we have to do is flip the build directive and if it's Release, SetConnectionDebug will never execute.  If it's Debug SetConnectionRelease will execute, but it will then be replaced with the Debug one.  I could have coded a more elegant example, but my goal is to show you how the things work.

At this point, I can hear all of the ludites out there saying "Big deal, preprocessor directives are more 'readable' from my point of view (why is it that readability is always used to defend bad programming habits?) and that didn't save me any code.  Well, at this point, there might be some merit to that, but that's not because using Attributes isn't vastly superior, it's because this discussion needs some more elaboration (And just for the record, you can still use Preprocessor directives and ATTRIBUTES, and that alone indicates their superiority if nothing else).  Let me elaborate on this point some.  There are many instances where we just use a block of code to do something.  We don't do it behind an object or a method or property.  We just write out a line of code (I guess in .NET it's still behind an object buy you get my point).  You can still code with your preprocessor directive here like so:

#if DEBUG        cn.ConnectionString = DebugConnectString; #else       cn.ConnectionString = ReleaseConnectString #endif

Notice something here!  The code in the #else is grayed out.  Why?  Because DEBUG and RELEASE are attributes and as soon as you use them (or anything else) the IDE looks to see if they are defined.  If they are, the IDE will have full Intellisense and make it obvsious that this is the one your are using.  If it isn't defined, then it will appear grayed out.  In this instance, my Build mode is set to Debug so the #else section is 'disabled'  That alone works wonders in helping you know what you defined without having to flip into the Project Properties window and see what you defined.  Since DEBUG and RELEASE are built into the IDE, it recognizes them without any intervention on your part.  Compare that to your own Compiler constants and the benefits of Attributes show themselves rather quickly.

But back to the other point.  One might argue that preprocessor directives are still good, but just make an adjustment and use the built in ones where applicable.  That still doesn't hold water.  You see, DEBUG and RELEASE are Attributes and you can build your own.  Then, you can set them in a configuration file and once again, at design time you know if something is set or not, have Intellisense and have a central place to manager everything.

Because .NET supports attributes, and you can attach them to any object, any method, any property, you all of a sudden have a lot of power.  Let's modify the scenario.  Using the connection manager object that we just had, lets say that we want to use the IDE to build our SQL Connections.  One reason many people don't use the designer is because they believe they will 'hard code' the connection string.  However, this isn't true.  You can use Attributes again, and Associate this attribute with your connections.  Then from one central place you can change all of them.  Also, if you use attributes, you can add as many as you want, they aren't mutually exclusive.  So, I could define a ConnectionString Attribute in my .config file and point all of my connections to it.  I could have a DEBUG and a RELEASE VERSION set up.  Then, I could change my ConnectionString whenever I wanted to without recompiling my project and I could switch from RELEASE to DEBUG on the fly (after all, in my example above I'm hard coding my ConnectionStrings which is flawed for many reasons from Security to Portability, but that's another story).  

So, drag a SqlConnection onto a form. From there, click on the Dynamic Properties in the Property Grid (they aren't called Dynamic for Nothing!) and click in the Advanced Property (since there can be muliple attributes set up, you'll notice the elipsis "..." in the right hand side.  When you click this, the Dynamic Properties Dialog will appear and on the left hand side you'll see a Properties ListBox with a ConnectString property, on the right hand side you'll see Key Mappings and in the combobox, SqlConnection1 which is the name of the current SqlConnection.  If you Check the ConnectionString Property the IDE will add a Configuration File (see below) named app.config for desktop apps or web.config for web apps (although ASP.NET creates config files by default)