There was quite a bit of uproar regarding my rant about C# regions. At the time, I was looking through a lot of really bad code, and I was pretty peeved at how all the pieces of complex code were hidden away by Visual Studio.  However, some of the comments seemed to imply that there is no such thing as “perfect” or “good” code when you refer to code written by someone other than yourself. And, to be honest, that is true: I like to think the code I write is better than most other developers. However, I want to qualify what better is:

Better code is:

• Code that is tested
• Code that is maintainable
• Code that is understandable by someone other than me
• Code that is changeable by someone other than me

Even with those guidelines, there is still some room to define more terms, but we have to stop at some point. Notice how none of these points really points to Lines of Code, the degree of algorithm obfuscation or how low the average cyclomatic complexity is for your codebase. These bullet points take a professional approach to the software development profession. That is, I and many others are professionals, and we should write our code as professionals. I hold myself to the same high standards as I hold others. Granted, I don’t meet those standards all the time either. I try not to beat myself up about it, because I would never win.

However, I wanted to be less emotional about why regions are really not that great. Just flat out, the main reason I see is that when you encapsulate code in region blocks, you miss an opportunity for one of many refactorings. In other words, you are knowingly violating principles of good software development by hiding the “bad” code under the rug.

Regions are simply comments preprocessor-style comments. As with normal comments, they are removed before the code is compiled, and are only there to help our non-digital brains cope with the mess we created in the first place.

I try my best to follow the TDD (and by extension, BDD) methodology, and so far, I have found no need for regions. Ever. I find that they clutter the code. I also find that TDD manages the mess I create much better than regions because they are like little pieces of thoughts that stick around to keep verifying my intentions several features back. TDD is by no means a do all methodology, but it has saved my butt several times, and does tend to make you write code that is neat, well tested, well organized and region free.

This is so last minute notice, but tomorrow is the Desert Code Camp in Tempe, AZ. I’ve attended the last few code camps, and they’ve been loads of help to me and my career in software development. This year, I decided that I should try to give something back, so I’m presenting on a couple of topics: Test Driven Development, and Behavior Driven Development. I’ve been practicing and evangelizing TDD for a couple of years now, and this is yet another outlet to try to convince others that this is the path toward code enlightenment.

Spoiler Alert: BDD on the other hand is somewhat new to me. However, as I’ve read many of the descriptions, and BDD testing frameworks, its really all about the way you look at tests, and the eventual evolution of what your firstly written unit tests eventually become: behavior specifications. I will be talking about the little I’ve learned about rspec, nspec, and nbehave tomorrow.

See you all tomorrow!

I’ve been a huge fan of Rhino Mocks since I heard about it on a way-back-episode of Dot Net Rocks HanselMinutes. One of the more awesome features of Rhino Mocks is that it utilizes a Record/Playback semantic so that you can set up your mocks with actual calls to the mock objects, then play them back in your tests. This is great if you rely on intellisense when calling your object instances, or if you use Resharper or another code refactoring tool.

Recently, I trying to use Rhino Mocks with DataTables like so:

DataTable a = new DataTable();
DataTable b = new DataTable(); 

MockObject mock = mockRepository.CreateMock<MockObject>();

using (mockRepository.Record())
{
   Expect.Call(mock.CreateRecord("TableName", a, b).Return(1);
}
using (mockRepository.Playback())
{
  MyObject obj = new MyObject(mock);
  obj.Save();
}

When I ran the test, Rhino Mocks says that a the DataTable created during the obj.Save() call wasn’t the same as the one expected. This was correct as there were now two instances, and it seems that the default check Rhino Mocks performs is an Object.Equals(). Since I needed to do some more deep comparisons of the Expected and Actual DataTables, a fellow developer and I started a very simple DataTableConstraint:

    class DataTableConstraint : AbstractConstraint
    {
        private readonly DataTable _expected;
        private string _errorMessage;

        public DataTableConstraint(DataTable expected)
        {
            _expected = expected;
        }

        public override bool Eval(object obj)
        {
            DataTable actual = obj as DataTable;
            if (actual == null)
                return false;

            if (!CheckColumns(actual))
            {
                return false;
            }
            if (!CheckData(actual))
            {
                return false;
            }
            return true;
        }

        private bool CheckData(DataTable actual)
        {
            if (actual.Rows.Count == 0)
            {
                _errorMessage = "Actual table has no data to compare";
                return false;
            }
            try
            {
                for (int i=0; i < _expected.Rows.Count; i++)
                {
                    foreach (DataColumn column in _expected.Columns)
                    {
                        object expectedCell = _expected.Rows[i][column];
                        object actualCell = actual.Rows[i][column];

                        if (expectedCell != actualCell)
                        {
                            _errorMessage = string.Format("Expected {0} in Row ({1}), Column ({2}), but was {3}", expectedCell, i, column.ColumnName, actualCell);
                            return false;
                        }
                    }
                }
                return true;
            }
            catch (System.Exception e)
            {
                _errorMessage = e.Message;
                return false;
            }
        }

        private bool CheckColumns(DataTable actual)
        {
            foreach (DataColumn column in _expected.Columns)
            {
                if (!actual.Columns.Contains(column.ColumnName))
                {
                    _errorMessage = string.Format("Could not find column {0} in {1}", column, actual);
                    return false;
                }
            }
            return true;
        }

        public override string Message
        {
            get { return _errorMessage; }
        }
    }

To use this using the above sample code, do

Expect.Call(mock.CreateRecord(null, null, null).Constraints
(
  Is.Anything(),
  new DataTableConstraint(a),
  new DataTableConstraint(b)
);

Now, this is just a start, and will probably evolve more as I start to get more into verifying the data in two tables. Perhaps Oren will create a new Syntax Helper along the lines of Data.Equals(expectedDataTable) since using a new Constraint() call is a little awkward.