Helper Code

Why you need to make your tests fail

noreply@blogger.com (Dror Helper) — Wed, 15 Feb 2012 20:50:00 +0000

Test Driven Development (TDD) have many benefits. For start it’s a design methodology that help avoiding “Analysis paralysis” and make sure that you only have the needed code to solve a problem.
Yesterday I found another benefit of writing the tests before the code – you get to see them fail!
A while back I wrote about another shortcoming of MSTest – how it does not have any built in facility to test against expected exception message.

Unknown to me at the time there was a bug hidden in the code I’ve published – see if you can spot it:

public static class MyAssert
{
    public static void BadThrows;<T>(Action action) where T : Exception
    {
        try
        {
            action();

            Assert.Fail("Exception of type {0} should be thrown.", typeof(T));
        }
        catch (T exception)
        {
     // All is well!
        }
    }
}

BTW this example was simplified for your viewing pleasure - I want to make a point here, not stick to the facts. have you found the bug yet?

Consider the following test:

[TestMethod]
public void ThisTestWouldNeverFail()
{
    MyAssert.BadThrows<exception>(() => Dummy.SomeMethod());
}

Have you guessed it? (hint: its in the test name)

That's right! this test would never have failed. If we take a closer look at BadThrows we’ll see the problem.

MSTest just like any other .NET unit testing framework throws an exception when assertions fails. In this case because we’re expecting an exception of type Exception any other exception thrown including the AssertFailedException would be caught – causing the test to pass.

That’s right – because the user expects an exception of type”Exception” to be thrown plus a minor bug the test is completely useless – if you want to see the working code just head to this post.

I did not find this bug mainly because I don’t like to throw and assert for Exception seems like a bad practice and in retrospective I should have avoided my co-workers from doing so by throwing exception of my own in case they try to do it.

The guy that did find this bug found it because he wrote a test and wanted to see it fail. That’s right it wasn’t enough for him to know that his code made the test pass – he had to make sure that it failed first – some people…
A quick search in our code found multiple tests that did exactly that which means two things:

These test were not written using TDD
The authors did not even bother to see the tests fail

After fixing the bug we found one test that started failing – which means that not only was the test wrong – so was the code it was testing.

I’ve talked to the team, explained why throwing “Exception” is not a best practice and why tests need to be “tested” by seeing them fail and we’ve fixed the tests and the code.

I think I learnt quite a lot from this experience, I know now who does TDD and who doesn’t and I found a new problem that occurs when developers write their tests after the code.

Happy coding…

The developer’s perspective

noreply@blogger.com (Dror Helper) — Sat, 28 Jan 2012 15:54:00 +0000

You’re lucky you know, said the developer to the consultant. You get to come and save the day and leave before all hell breaks loose.

You got it all wrong said the consultant to the developer. I solve problems, teach best practices and explain what should be done and then they change and twist everything I said and done 5 seconds after I’m gone.

I wanted to share part of a conversation I had with a consultant I know.

SCISR Meeting with Corey Haines

noreply@blogger.com (Dror Helper) — Thu, 26 Jan 2012 20:58:00 +0000

Today I attended a meeting of the Software Craftsmanship in Israel group with Corey Haines.

Corey gave a talk about agile practices and how to decide which to choose.

The talk went something like this:

Our objective is to reduce the time between doing something and doing the right thing and the time between doing one thing and starting the next one. And thus the goal of every single methodology is to make the feedback loop smaller – at all levels.

The main reason we want to reduce the feedback loop and provide value as soon as possible is that we want to minimize the cost of change. The cost of adding feature decrease over time – the promise of agile/code craftsmanship is that that time would not be exponentially – it would still be fairly easy to add a new feature a year from now.

Usually systems begin simple and beautiful and over time as the features accumulate it becomes more and more complicated. This can be handled by using evolution design/Iterative design which means that you take the time to clean your work after adding a feature instead of rushing to the next task on your to do list.

Early feedback by giving product early. Because it’s much nicer to change a system when its small. Thus reducing the time between doing something and finding out what you should have done.

The second part of the session was about testing and on how to reduce the Dev-QA feedback cycle which is why too long. In essence the objective is to know if the code today works as well as our code yesterday or even if our code work as well as 5 min. ago. Corey has talked a while about testing and automation and how to reduce the time to deployment.

One of the key points I liked was that we shouldn’t discuss whether or not a methodology A is better than methodology B we should discuss the value we’ll receive from using that methodology.

And finally a simple rule: If you choose not to use a practice, you must replace it with another of equal value.

Corey has answered a few questions from the audience about how to evaluate the cost of certain practices, mocking and working with legacy code followed by a short exercise – we had to parse Piet code by hand – namely the following “program”:

I caught two of Typemock’s finest – Gil Z. and Elisha writing a parser using unit tests and what looks to be a new soon to be released tool.

All in all an evening well…

Just a quick reminder

I’ll be presenting at the Agile Practitioners conference next week – so don’t forget to come and say hi. And incase you’ve missed Corey’s session or want to hear more of what he has to say about agile and software development in general – come to the Agile Practitioners conference next week.

Didn’t sign up yet – don’t worry because registration is still open. Just tell them I’ve sent you or better yet use this link.

See you there!

The evolution of a task board

noreply@blogger.com (Dror Helper) — Fri, 13 Jan 2012 16:11:00 +0000

I’d like to tell you a story about how we manage tasks in my team…

Once upon a time (about a year and a half ago) I’ve started working in a new place. Since I’ve came from a company with very strong agile practice I wanted my new work place to be as agile as possible – and one of my first “missions” was to improve the way the team’s task tracking.

Task Board #1 – Sticky notes

I’ve convinced my manager to start using a “task board” which consisted of using sticky notes and one of the walls of the office. And as simple of that we had all of the team’s tasks in a simple, easy to read (and understand) display for the entire world to see. And the improvement was felt immediately. The team members could tell what are the priorities and their current and future work. And the team’s manager was happy because now it was clear what each of us were doing.

Some of the team liked the idea, some not so much… And over time it was clear who was updating his current progress and who’s tasks didn’t change on the board for the last two iterations.

Task board #2 – Distributed

I’ve done a quick check with the team to understand how we can improve the task board and one of the problem raised was that because the tasks were displayed on a wall that was less accessible to some of the team members they didn’t update their tasks as often as possible – instead of moving tasks from To-do to In progress and then Done they waited until several such “updates” were accumulated (or until they happen to pass by the wall) before moving the tasks on the board.

And so we’ve found a solution – each developer had his own task board right above his head. I know it’s not SCRUM but it worked for us.

And so we’ve continued working this way for a few months until another challenge presented itself…

From time to time a developer had to work on site which meant that he was out of the office and could not update his backlog another problem was that as the project progressed more and more top managers needed to know what the team is doing and whether or not we were reaching our goals. At about the same time the team has grown and we now were filling two rooms and looking to hire more developers and my manager had problems tracking the team’s goals.

Task board #3 – Excel spreadsheet in shared folder

Building upon past experience my manager came up with a simple Excel spreadsheet that was placed in a network share and that the team could update. The advantage was that Excel files can be copied, sent on email and shown at meetings a fact that helped explain what we were doing and how much time it would take to project managers, product owners and top management of our company.

We worked with the excel for a few iterations and it worked for us – we could move tasks between the team and everyone knew what everyone did. But the more we’ve used it the more it became clear that this “Excel task board” was holding us back. Since only one user is allowed to update the file – whenever two developers needed to update their progress it caused us grief – especially before start/end of iteration when all of us needed to update the file at once. Another problem was that once an iteration ended another file/book was created and the old iteration data was “archived” never to be seen again.

We knew we needed a better solution and we’ve found one just under our nose – TFS. We were already using TFS for source control and continuous integration (CI) server so why not use it to track our tasks as well.

Task board #4 – TFS + Work Item Manager

I was able to update the TFS Task using Visual Studio and we had a simple SCRUM workflow:

Using this task we were now able to use TFS as our backlog and task board. Another added bonus is that using Telerik’s TFS Work Item Manager we were able to see the old task board we were used to see on the office wall:

Now we had it all:

System that we can update easily – from the comfort of our Visual Studio

Easy to understand visualization

Statistics on iteration, remaining tasks and team progress

Project dashboard

And this is how we work today.

Conclusion

The lesson of this tale is that you should not be afraid to change. Just because we were using a tool that worked for us in the past didn’t mean that that tool cannot be changed if a better alternative is available, or if he required functionality changes. Because being agile is embracing change not just in the product you’re delivering but also the way you deliver it.

One final note

Using a task board is a simple practice and yet many teams just don’t track their tasks properly. Showing my team to use a task board is only one of the ways I’ve used to make them more “Agile”. If you’d want to learn more about how to make your team more agile or looking for tips and tricks that I found useful – I’ll be talking about it on my session at the Agile Practitioners Conference at the end of this month.

Happy Coding…

TDD vs. BDD or why can’t we all just get along?

noreply@blogger.com (Dror Helper) — Sat, 10 Dec 2011 17:11:00 +0000

I was listening to another good Hanselminuets podcast - Understanding BDD and NSpec with Matt Florence and Amir Rajan. As always it was a good an informative show. Towards the end of the show one of the interviewees (I think it was Amir) explained why BDD is much better than TDD…

by djclear904

For those of you who does not know what I’m talking about – TDD is Test Driven Development (or design) and BDD is Behavior Driven Development. TDD is more “low level” talking about unit tests and integration tests and how to write code that test code while BDD is about specifications and behaviors.

In TDD we talk about Arrange Act Assert while in BDD we have Given When Then

Each methodology has its own frameworks that help write and run tests (or specifications) that make sure our code does what it meant to do.

Am I the only one that see a resemblance?

You might argue that one is better than the other till you blue in the face it does not change the fact that they are two sides of the same coin.

There are differences – BDD is more “high level” dealing with specifications and was intended to be used by domain experts as well as developers – although I’m yet to find the product manager that would write specifications. On the other side TDD is developer oriented and intended to be used by people who write and read code daily.

But regardless of these differences I don’t really see a reason why you should choose one over the other. I confess I use TDD and unit/integration tests in most of my projects but I do have several projects where I use both. I like the fact that I can write unit tests as well as specifications – because I need to test both. I also find myself using unit testing framework (i.e. NUnit) to write more “BDD’ish” kind of tests.

And so I don’t really understand why one is better than the other. Mainly because I prefer to use both – when possible.

And if you never tried BDD (or TDD) before I suggest you do and see for yourself.

Happy Coding…

Refactor “if” statements - functional programming style

noreply@blogger.com (Dror Helper) — Tue, 22 Nov 2011 16:46:00 +0000

Have you ever seen code that look like this:

public string GetStatusDescription(Model model)
{
    if(model.HasProblemReports)
    {
        return "Errors";
    }

    if(model.SystemState.WorkingMode == WorkingMode.NotManaged)
    {
        return "Manual";
    }

    if(model.SystemState.IsInitializing)
    {
        return "Initialize";
    }

    if(!model.SystemState.InService)
    {
        return "Not in service";
    }

    if(model.SystemState.WorkingMode == WorkingMode.Paused)
    {
        return "Paused";
    }

    if(model.Storage.Objects.Any(obj => obj.IsMoving))
    {
       return "Movement in storage";
    }

    return string.Empty;
}

I know I have – yesterday, I’ve changed the variable names and removed a bit of plumbing code but in essence this is a real function I had to work with.

The problem with this kind of code that it start out simple but quickly becomes hard to read and maintain. Because the ordering of the “if” statements matters as much as the condition itself.

One solution is to use the well known Chain of Responsibility pattern. although it would probably work in this case, I’ve noticed that developers shy from using it in code similar to this example. It’s as if they feel that they “waste” good code by creating a”whole class for two lines of code”. Another reason not to use CoR is that in this case I don’t want to encapsulate the logic of this method in a lot of classes – I just want to be able to easily understand what the method does and add/remove/update it easily.

I literally felt pain writing each new “if” statement until I could take it no more and so I’ve decided to refactor it.

First I’ve created a class to hold each condition:

class ModelToMessage
{
    private Func<Model, bool> _predicate;

    public ModelToMessage(Func<model ,="" bool=""> predicate, string message)
    {
        _predicate = predicate;

        Message = message;
    }

    public bool IsValid(Model model)
    {
        return _predicate(model);
    }

    public string Message{get; private set;}
}

Using this new class I was able to declare the following list and refactor my method:

private List<modeltomessage> _messageCreators = new List<modeltomessage>
    {
        new ModelToMessage(model => model.HasProblemReports, "Errors"),
        new ModelToMessage(model => model.SystemState.WorkingMode == WorkingMode.NotManaged, "Manual"),
        new ModelToMessage(model => model.SystemState.IsInitializing, "Initialize"),
        new ModelToMessage(model => !model.SystemState.InService, "Not in service"),
        new ModelToMessage(model => model.SystemState.WorkingMode == WorkingMode.Paused, "Paused"),
        new ModelToMessage(model => model.Storage.Objects.Any(obj => obj.IsMoving), "Movement in storage"),
        new ModelToMessage(model => true, string.Empty),
    };

public string GetStatusDescription(Model model)
{
   var messageCreator = _messageCreators.First(mc => mc.IsValid(model));

    return messageCreator.Message;
}

The last item on the list is the “default” item that is always true and return an empty string.

I really like the fact that it’s easy to understand which message comes before which message and it’s easy to add new conditions and change their priority.

Happy coding…

List executed code using PostSharp

noreply@blogger.com (Dror Helper) — Sun, 06 Nov 2011 18:52:00 +0000

This post was created to answer a question by Laimonas Simutis on the ALT.NET mailing list – how to list all executed code…
There where many good ideas and your truly suggested using PostSharp – mainly because this is one of the examples I use in my AOP and PostSharp presentation. And so without further ado here is my solution for your consideration:

The “tracing” attribute

For this purpose I choose to use OnMethodBoundaryAspect which enable me to add hooks on method’s enter and exit:

[Serializable]
[MulticastAttributeUsage(MulticastTargets.Method, AllowMultiple = true)]
public class TraceMethodCallsAttribute : OnMethodBoundaryAspect
{
    private string _methodName;

    public override void CompileTimeInitialize(System.Reflection.MethodBase method, AspectInfo aspectInfo)
    {
        _methodName = method.DeclaringType.Name + "." + method.Name;
    }
    

    public override void OnEntry(MethodExecutionArgs args)
    {
        Console.WriteLine(">> {0}", _methodName);
    }

    public override void OnExit(MethodExecutionArgs args)
    {
        Console.WriteLine("<< {0}", _methodName);
    }
}

This is your simple method boundary aspect which is good to add custom functionality before and after method call as well as on exception and/or successful completion. This time I only needed the enter and exit functionality.
My attribute has several attribute of it’s own, one simple for serialization and the other is where the magic happens – the MulticastAttributeUsage that tells PostSharp that this attribute should be automatically applied to every method in the class or assembly.
Other than that I’ve also used CompileTimeInitialize in order to save some cycles by “calculating” the method name only once (at compile time) instead of each time the method is called.

Using the attribute

Now all I have to do is add this line to the AsseblyInfo.cs file:

[assembly: TraceMethodCalls]

And that’s it – running the following program:

class Program
{
    static void Main(string[] args)
    {
        var a = new A();
        for (int i = 0; i < 3; i++)
        {
            a.MethodOne();
            a.MethodTwo();
        }
    }
}

public class A
{
    public void MethodOne()
    {
        Console.WriteLine("I am in method one");
    }

    public void MethodTwo()
    {
        Console.WriteLine("I am in method two");
    }
}

Provides the desired result

Happy coding…

Three .NET "tools" that I use every day and you want to know about

noreply@blogger.com (Dror Helper) — Sat, 29 Oct 2011 08:09:00 +0000

Time is a very limited and expensive resource. As a software developer I feel more often than not that I just don’t have enough of it…

That’s why whenever I find a new library or tool that save me time I embrace it with both hands, especially if they preform tasks that I find boring and tedious.

the following is a short list of three such tools that I find myself using daily because using them means that instead of writing the same code over and over again I get to focus on more interesting aspects of my job.

Configuration Section Designer

What is it: Visual Studio (2008/2010) add-in
License: Microsoft Public License (Ms-PL)
Website: http://csd.codeplex.com

Most project I know have some form of configuration, in the .NET world it usually means one or more XML files that have various key-value pairs that are used to store “configurable” application settings. The problem is that if you want to harness the full power of configuration that is available you have to learn quite a lot about configuration sections and/or write quite a lot of boilerplate code to serialize and de-serialize the configuration files properly.

Enter Configuration section designer – a visual studio add-in that help create and edit configuration sections (structure) visually. It’s really simple to use and about after 5 minuets you’ll be able to use it to create the configuration files you’ve always wanted.

After visually creating your configuration design you get the following:

XSD schema that you can use to add intelligence to your configuration files creation process
A config fie with simple outline that you can fill.
C# serialize/de-serialize file that is simple and easy to use to load/save the files from your application

CSD saves me hours each week - It slices, it dices and it verifies that your configuration is valid. I can created custom types and converters and it manages to stay simple and easy to use.

This open source project was dormant for quite some time and I’ve started to think its development was stopped, but I’m glad I was wrong with the new version that supports VS2010 CSD seems more alive than ever!

AutoMapper

What is it: .NET library
License: MIT license
Website: https://github.com/AutoMapper/AutoMapper

I hate writing conversion code. Converting one class to another class is tedious, error prone and it feels just “wrong”.

The problem is that there are quite a lot of architecture solutions that requires converting object from system A to a different object in system B. Luckily with AutoMapper all of the A.X = B.Y code just go away.

Mapping from the application’s internal object mode to DTO (Data Transfer Objects) or view model has never been easier. With a plethora of conversion abilities from simple property to property mapping up to custom converters. And if you build your classes the right way most of the conversion is done automatically.

It’s well documented and has a very good getting started guide that would get you up and running in no time. Using it at work was a simple matter of Add reference and I was ready to go. Since then AutoMapper has helped me rid of quite a lot of hard to read, error prone lines of code.

PostSharp

What is it: .NET library
License: Commercial (has free edition)
Website: http://www.sharpcrafters.com/

I’ve started been using PostSharp extensively and never looked back. I keep finding new ways to harness its power and I’m happy to see that more and more of my co-workers are solving problems easily using AOP (Aspect Oriented Programming).

Using PostSharp I’m able to create “attributes” that encapsulate cross-application concerns and I’ve stopped counting the times that my logging attribute has helped us track a bug in one of our servers.

Conclusion

With each new tool under my belt I become better at my job. The examples above are only three such tools and I’m always happy to learn about a new one I can use.

So if you enjoy learning new tricks - try them for size and decide if they’re good for you.

Happy coding…

Agile toolkit session at ILTAM

noreply@blogger.com (Dror Helper) — Wed, 05 Oct 2011 18:26:00 +0000

Today I had the pleasure I had a session at ILTAM where I talked about the tools used in an agile software development. It was a mixed crowd of software developers, testers, team leads, project managers (and change) and it was fun trying to make the topic relevant to all of the audience at the same time.

Agile toolkit

View more presentations from Dror Helper.

Happy coding…

Essence of agile

noreply@blogger.com (Dror Helper) — Tue, 20 Sep 2011 20:54:00 +0000

Recently I had the pleasure to meet two developers with very different “styles” of software development. The first have never heard of SCRUM and never practiced any of the agile methodologies while the second is a certified SCRUM master and has used SCRUM to manage his team.

Both were given a problem to solve in one hour, although both haven't finished writing when time was up I learnt quite a lot from the bits they did finish.

Both finished about 50% of the required functionality but while one had one working feature the other only managed to finish the “infrastructure” needed to solve the problem. Although it can be argued who done a better job, it is clear which of the solutions is “more agile” (hint – the one that provide value).

The weird thing is that the developer without any “formal” agile experience choose to implement the solution vertically one feature at a time while the agile savvy developer got stuck implementing “architecture” showing zero value when his time was up.

So what do you think – which one knows more about what agile means?

Enabling parameterized tests in MSTest using PostSharp

noreply@blogger.com (Dror Helper) — Wed, 07 Sep 2011 19:49:00 +0000

I have blogged about the shortcoming of Microsoft’s unit testing framework in the past. It has very good Visual Studio (and TYFS) integration out of the box but it seems that in order to use it I have to suffer lack of functionality I’m used to taking for granted when using any other .NET unit testing framework out there. ON the of feature I miss most is RowTest (Theory for you XUnit users). When using MSTest I want to be able to create a test that receive parameters. It shames me to have to tell a co-worker to write 10 (or more) different tests that test the exact functionality with differed conditions.

There is a way to run parameterized tests in MSTest namely data-driven tests the downside is that you have to create an external file to host the parameters making the test less readable to my taste. Another alternative is to use MSTest that comes with VS2010 and extend it – I wrote about it in a previous blog post.

I’ve decided to create another solution for those of you that do not use VS2010 and .NET 4 or do not want to extend the testing framework – using data-driven test and the power of PostSharp.

The incidents

One test marked as a test class no parameters
One test with the same name with parameters
One simple RowAttribute to keep the parameters
One PostSharp OnInvocation attribute to do all of the magic
Mix & Run

The Test(s)

Because of MSTest limitation will need two functions with the same name. The first one without parameters will be used as a host test method to run and the second will contain the actual test code:

[TestClass]
public class MyRowTests
{
    public TestContext TestContext { get; set; }

    [TestMethod, RowTest]
    [DeploymentItem(@"..\..\SimpleRowTest.xml")]
    [DataSource("Microsoft.VisualStudio.TestTools.DataSource.XML",
     "|DataDirectory|\\SimpleRowTest.xml",
     "Row", DataAccessMethod.Sequential)]
    public void SimpleRowTest()
    {

    }

    [Row(1, 2, 3)]
    [Row(3, 2, 5)]
    [Row(3, 4, 9)]
    [Row(3, 4, 7)]
    public void SimpleRowTest(int x, int y, int result)
    {
        Assert.AreEqual(result, x + y);
    }
}

The first method is the one MSTest know and respect and we’re going to use it to run the second method. I’ve added DeploymentItem and DataSource attribute to run the xml file that is going to be generated with the data from the Row attributes.

Note: It is important that the deployment item would point to the relative path of the test project file from the solution file – this is one nasty bit of code and I wish I could find a way to throw it away.

Note: It is crucial that you have TestContext defined in the test class as well – otherwise MSTest won’t be able to access the test’s parameters:

RowAttribute

This is a plain old C# attribute – nothing special, just a container to hold the row test data:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = true)]
public class RowAttribute : Attribute
{
    private readonly object[] _rowParameters;

    public RowAttribute(params object[] rowParameters)
    {
        _rowParameters = rowParameters;
    }

    public object[] Parameters
    {
        get { return _rowParameters; }
    }
}

It’s marked to be used on a method and that it can be applied multiple times and that’s it./p>

RowTestAttribute

This is where the magic happens! The attribute does two things:creates a xml data source file and run the method with the parameters. Inheriting from MethodInterceptionAspect enables hooking into two events – compilation of the class and when it runs:

[Serializable]
[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public class RowTestAttribute : MethodInterceptionAspect
{
    private MethodInfo _methodToInvoke;

    public override void CompileTimeInitialize(MethodBase method, AspectInfo aspectInfo)
    {
        base.CompileTimeInitialize(method, aspectInfo);

        _methodToInvoke = method.DeclaringType.GetMethods(BindingFlags.Instance | BindingFlags.Public).Single(info => info.Name == method.Name && info != method);

        var rowAttributes = _methodToInvoke.GetCustomAttributes<RowAttribute>();

        CreateDataSource(_methodToInvoke, rowAttributes);
    }

    public override void OnInvoke(MethodInterceptionArgs args)
    {
        var testContext = args.Instance.GetPropertyValue<TestContext>("TestContext");

        var parameters = _methodToInvoke.GetParameters();

        var arguments = testContext.GetParameterValues(parameters);

        try
        {
            _methodToInvoke.Invoke(args.Instance, arguments.ToArray());
        }
        catch (TargetInvocationException exc)
        {
            // fix stacktrace
            FieldInfo remoteStackTraceString = typeof(Exception).GetField("_remoteStackTraceString", BindingFlags.Instance | BindingFlags.NonPublic); // MS.Net

            remoteStackTraceString.SetValue(exc.InnerException, exc.InnerException.StackTrace + Environment.NewLine);

            throw exc.InnerException;
        }
    }        

    private string CreateDataSource(MethodBase testMethod, IEnumerable<RowAttribute> customeAttribute)
    {
        var projectFileName = PostSharpEnvironment.Current.CurrentProject.EvaluateExpression("{$MSBuildProjectFullPath}");
        var projectPath = Path.GetDirectoryName(projectFileName);
        var filename = Path.Combine(projectPath, _methodToInvoke.Name + ".xml");

        using (var sr = new XmlTextWriter(filename, Encoding.ASCII))
        {
            sr.WriteStartDocument();
            sr.WriteStartElement("Rows");
            foreach (var rowAttribute in customeAttribute)
            {
                sr.WriteStartElement("Row");

                for (var i = 0; i < rowAttribute.Parameters.Length; i++)
                {
                    sr.WriteStartElement("value" + i);
                    sr.WriteValue(rowAttribute.Parameters[i]);
                    sr.WriteEndElement();
                }

                sr.WriteEndElement();
            }

            sr.WriteEndElement();
            sr.WriteEndDocument();
        }

        return filename;
    }
}

There are three main functions:

CompileTimeInitialize – that get called when the code compiles and is responsible to create the XML file – remember we need it before the test runs
OnInvoke – called when the test runs. Reads the data from the data source and convert the parameters before running the second (parameterized) method
CreateDataSource – you’ve guessed it – this is where we create the xml file – simple and dirty… I use PostSharp’s EvaluateExpression to find where the project’s file is – remember this bit runs on compile so no tricks using reflection could be used to find the target assembly.

Utilities

Simple methods I use in the RowTestAttribute – just in case you’re wondering:

public static class Extensions
{
    public static IEnumerable<T> GetCustomAttributes<T>(this MethodBase method) where T : Attribute
    {
        return (T[])Attribute.GetCustomAttributes(method, typeof(T));
    }

    public static T GetPropertyValue<T>(this object instance, string propertyName)
    {
        var propertyInfo = instance.GetType().GetProperty(propertyName);
        return (T)propertyInfo.GetValue(instance, null);
    }

    public static IEnumerable<object> GetParameterValues(this TestContext context, ParameterInfo[] parameters)
    {
        for (var i = 0; i < parameters.Length; i++)
        {
            var parameterType = parameters[i].ParameterType;
            var inputData = context.DataRow["value" + i];

            yield return Convert.ChangeType(inputData, parameterType);
        }
    }
}

Running the test

MSTest force me to run the empty parameter-less method. Running the test from the beginning of this post will result in the following:

How cool is that – The “test” is actually 4 tests run separately and one of them failed – with a clear error message. And there’s more clicking on the test we get to see the full error message:

In fact I was so impressed with how it works that I put it to us at work despite the fact that it’s not finished yet.

Is it done?

Not yet – I would really like to throw away the DeploymentItemAttribute and if I can get away with it the DataSourceAttribute. I do use it daily and it feels just wrong.

I’ve tried creating the attributes in runtime – using PostSharp but Visual Studio was not fooled – probably because DTE is used to collect these attribute and not reflection.

By publishing this post I was hoping to achieve two goals:

Help other lost souls such as myself that are forced to use MSTest but wish they had the ability to run RowTests – BTW you’re welcome
Get feedback, suggestions and ideas how this nifty idea can be improved

And please let me know if you put this code to use – that’s what the comments are for

Happy coding…

9 years ago…

noreply@blogger.com (Dror Helper) — Wed, 17 Aug 2011 14:58:00 +0000

August 2002 I’ve started my first “real” programming job, I was an intern at Intel working side by side with intelligent and talented engineers on a performance monitoring tool for Linux. A lot has happened since, I switched a few jobs, sometimes I worked for big enterprise and sometime for a small startup until I ended up on my current position in a company that is neither (or both).

I wrote software that did video processing, ecommerce and helped people write better unit tests (I hope) mostly (but not only) in C++ and .NET languages where I felt most comfortable.

by Raymond Brettschneider

In the last nine years I learnt quite a lot in the since I wrote my first void main - on my first job I leant how to write code, on my second job I learnt how to write code fast but only on my previous job did I learn how to write code well…

In every job and every project I had a the good fortune to find guru that could teach me something and with each lesson I improved not only professionally but also as an individual.

All in all it’s been fun ride, it’s not over - I’m just stopped for a minuet too look back and take a breath.

I can’t wait to see what would happen in the next nine years.

Supercharge Isolate.Verify

noreply@blogger.com (Dror Helper) — Mon, 01 Aug 2011 07:15:00 +0000

At work we use Typemock Isolator for all of our Isolation/Mocking needs. Lately I’ve noticed that my co-workers do not like to use verify. One of the reasons they prefer not to use it is that sometime Verify error messages leave much to be desired. There are a few simple tricks that helps Isolator help you when using verify and I’m going to show them right here in this very blog post.

What is this verify you talk about?

Any Isolation framework worth mentioning can do the following three features:

Create fake object (a.k.a mock/stub/test dummy – you name it)
Set expectations on fake objects
Verify method was called in fake object

Verify is what differentiate mock from stub. Without getting into too many definitions a mock object is a fake object that can assert that methods were called inside of it and even check if it was called with specific arguments.

So what’s the problem with verify?

Verify is a powerful tool and should be used with care. Checking that method A called method B is not its purpose. You don’t want your tests failing just because you did a simple refactoring. Instead Verify should be used when the end result of the test is a method call and not a state, for example use it in a test that an email is sent to the client after a successful operation.

Oddly enough – that’s not the reason that developers tend not to like using it. The real reason is that unlike Assert that provides a clear and understandable message when fails some of the times Verify message is not clear enough. Good errors are crucial when test fails – it saves time by helping the developer understand the issue without needing to debug the code which equals faster development time.

And so we would like to improve the error message on the failing test to help understand why the test failed a few days/weeks/months after it was written.

Improving Verify error messages

Luckily for us the good people of Typemock have already thought about this issue as long as enough information is provided.

[Test]
public void VerifyStringParam()
{
    var cut = Isolate.Fake.Instance<ClassUnderTest>();

    cut.SomeMethod("this is the wrong string");

    Isolate.Verify.WasCalledWithExactArguments(() => cut.SomeMethod("this is the right string"));
}

The code is quite simple even if you’re not familiar with Isolator – in fact it’s too simple, I cannot think of a good reason to write this code other than to show my point.

First we create a fake object then we call a method on it and finally we check that it was called with a different variable.

We got the following error:

The error is exactly what I need – it tells me what went wrong and shows the first offending character in the sting. But what happens if I use a more complex parameter:

[Test]
public void VerifyComplexParam()
{
    var cut = Isolate.Fake.Instance<ClassUnderTest>();

    var myClass = new MyClass
    {
        Id = "wrongId",
        Data = 11
    };

    cut.SomeMethod(myClass);

    var expected = new MyClass { Id = "Id", Data = 5 };
    Isolate.Verify.WasCalledWithExactArguments(() => cut.SomeMethod(expected));
}

Here I use a more elaborate (yet useless) class as a parameter, and again I “accidently” call the method with the wrong parameter. Running the test would provide the following failure message:

SO what happened? the test failed but Isolator in his great wisdom offers us to implement Equals because 9 out of 10 times I don’t want to compare the parameters by reference just by their inside value. By implementing equality methods we can tell Isolator if the inside of the class is the same – after implementing Equals I get the following error message:

How cool is that! Isolator has used equals and when it failed assumed that one (or more) of the properties of the class are to blame and so it shows all of the properties in MyClass that are not equal.

But what happens if we pass a really complex class – one that contains another class?

[Test]
public void VerifyMoreComplexParam()
{
    var cut = Isolate.Fake.Instance<ClassUnderTest>();

    var complexClass = new ComplexClass
    {
         InnerClass = new MyClass { Id = "id", Data = 10 }
    };

    cut.SomeMethod(complexClass);

    var expected = new ComplexClass
    {
         InnerClass = new MyClass { Id = "Id", Data = 5 }
    };

    Isolate.Verify.WasCalledWithExactArguments(() => cut.SomeMethod(expected));
}

We get this error message:

Isolator has found that the problem was the parameter (duh) but he would not tell me what is wrong with it – I guess there is no option but to debug – wrong!

By overriding ToString we can improve the error message into this:

Even if Isolator won’t guess what is different between the classes at least he shows the string representation helping me discover for myself why the test failed.

You might have noticed that when using these simple tricks you can discover instantly why the test failed – without using debugger or even glancing at the source code – in fact throughout this post I never once showed the code for the class under test.

Happy coding…

Three Day TDD .NET Course (Israel)

noreply@blogger.com (Dror Helper) — Sat, 23 Jul 2011 09:31:00 +0000

A new practitioner of TDD and unit tests has much to learn:

how to what are acceptance tests?

how to write tests that won’t break on every trivial change?
what mock objects and why should you care?
How do I test my product code?

So if you’re looking for a place to learn all those look no further – Lior Friedman has opened a course on all things unit testing and TDD for .NET developers.

This three day course will take place at the 14th of August where students will learn how to write unit tests not only for simple “hello world” examples but also for complex real world systems – and everything in between.

The course outline and can be found here and Registration is open.

If you want to learn more just head to Lior’s site and check it out.

How to return default(Type) in runtime – a TDD example in four unit tests

noreply@blogger.com (Dror Helper) — Sun, 17 Jul 2011 11:24:00 +0000

I’ve found this question while going over my old StackOverflow answers:

I'm using reflection to loop through a Type's properties and set certain types to their default. Now, I could do a switch on the type and set the default(Type) explicitly, but I'd rather do it in one line. Is there a programmatic equivalent of default?

I encourage you to read till the end before checking my answer – because I want to show you how this task can be solved using TDD (Test Driven Design).

[From Wikipedia]

Test #1 – handle null input

Let’s write the first test – when null is passed return null:

[Test]
public void GetDefault_PassNull_ReturnNull()
{
    var result = DefaultCreator.GetDefault(null);

    Assert.That(result, Is.Null);
}

Now all we need is to make the test pass and so implementing this requirement is as simple as can be:

public class DefaultCreator
{
    public static object GetDefault(Type type);
    {
        return null;
    }
}

Although this seems like cheating this is the way to create the design piece but piece, instead of creating it all upfront I hope that things would get clearer in the process just keep in mind that the worse case scenario is that we have a test that checks what happens if null is passed.

Test #2 – reference types

Next test - if T is an object default(T) will return null:

[Test]
public void GetDefault_PassObject_ReturnNull()
{
    var result = DefaultCreator.GetDefault(typeof(object));

    Assert.That(result, Is.Null);
}

Running the test shows a cool feature of test driven design – the test passes! and so right now we have a class that satisfies two out of three of our requirements.

Test #3 – primitives

All we need to implement now is how to behave when a value type is passed – and so we write another test:

[Test]
public void GetDefault_PassInteger_Return0() 
{
    var result = DefaultCreator.GetDefault(typeof(int));

    Assert.That(result, Is.EqualTo(0));
}

And write the simplest solution that makes it pass:

public class DefaultCreator
{
    public static object GetDefault(Type type)
    {
        if (type == typeof(int)) 
        {
            return 0;
        }

        return null;
    }
}

So far so good but we’re not done yet – after writing a few more tests for double, float and long refactoring brought this solution:

public class DefaultCreator
{
    public static object GetDefault(Type type)
    {
        if (type.IsPrimitive) 
        {
            return 0;
        }

        return null;
    }
}

Test #4 – Structs

Still with me good – what about a complex value type :

[Test]
public void GetDefault_PassStruct_ReturnEmptyStruct() 
{
    var result = DefaultCreator.GetDefault(typeof(MyStruct));

    Assert.That(result, Is.TypeOf<MyStruct>());
}

Now that we have a failing test – we can add functionality to fix it:

public class DefaultCreator
{
    public static object GetDefault(Type type)
    {
        if (type.IsValueType) 
        {
            return Activator.CreateInstance(type);
        }

        return null;
    }
}

Run all of the tests and that’s it – we have a class that mimics default(T) at run-time one step at a time.

The end

Of course I could have created this class without unit tests but I wanted to show a simple (but not too simple) example that shows how to use unit tests as a design tool.

Happy coding…

RTFM–the tale of ReaderWriterLockSlim

noreply@blogger.com (Dror Helper) — Tue, 28 Jun 2011 18:22:00 +0000

The .NET BCL (Base Class Library) is readable, easy to understand and not less important documented. This is a story on where a simple reading of documentation could have saved us from a minor bug…

If you’ve been using .NET you might be familiar with the ReaderWriterLock essentially a lock that enable multiple readers or one writer synchronization. The only problem is that the good old ReaderWriterLock had a few drawbacks – and so the good people of Microsoft have create a new and improved ReaderWriterLockSlim.

A developer at my team had a simple task – make sure that there are not race conditions when reading and writing a big chunk of the project’s shared data and for the task he choose the trusty ReaderWriterLockSlim. He had two methods to access the data one for reading and one for writing – so far so good.

Fast forward a year and the team has a strange issue – it seems that only one thread can access the data – even if it’s only reading it. After a few debates my co-worker found the root of the problem – whenever a read was required instead of using EnterReadLock – which is used to, well acquire read permissions the original developer had used EnterUpgradeableReadLock. Perhaps because it’s enable using a write request from within the read lock – I have no idea since that developer has since left the team.

And according to MSDN:

Regardless of recursion policy, only one thread can be in write mode at any time. When a thread is in write mode, no other thread can enter the lock in any mode. Only one thread can be in upgradeable mode at any time. Any number of threads can be in read mode, and there can be one thread in upgradeable mode while other threads are in read mode.

Duh!

The problem was not that the original developer didn’t know that using an upgradable lock essentially creates a state where all the locks a mutually exclusive – just like using simple lock only without the performance benefits. The problem is that all of the team saw the code at one point or the other and not one of use thought of reading the page on MSDN that has the paragraph quoted above!

We had a simple policy of if it works – don’t break it and would have probably continue to use ReaderWriterLockSlim the wrong way unless a different issue caused us to take notice.

Happy coding…

Using null-coalescing to find item in multiple collections

noreply@blogger.com (Dror Helper) — Tue, 07 Jun 2011 08:56:00 +0000

A co-worker showed me this:

var result = collection1.GetObjectByAtSpecialLocation(location) ??
        collection1.GetObjectByAtLocation(parent, location) ??
        collection2.GetObjectByAtSpecialLocation(location) ??
        collection2.GetObjectByAtLocation(parent, location);

I’m still trying to decide whether it’s a good practice and if it’s readable or not…

In case you’re not familiar with ?? operator a.k.a null-coalescing operator it’s basically returns a default value if the left side is null so the following line means return empty string if name is null:

string result = name ?? string.Empty;

And so the code at the beginning of the post can also be written as:

var result = collection1.GetObjectByAtSpecialLocation(location);
if(result == null) 
{
    result = collection1.GetObjectByAtLocation(parent, location);
} 

if(result == null) 
{
    result = collection2.GetObjectByAtSpecialLocation(location);
} 

if(result == null) 
{
    result = collection2.GetObjectByAtLocation(parent, location);
}

Although most developers would agree that it’s easy enough to understand it’s far from being a good piece of code.

I also think that the reason that there was a need to check if an item exist over two different collections in two different ways indicates a design flow – but since we’re not living in a perfect world right now it’s impossible to merge those two collections and regardless of effort there was a good reason that they are different in the first place so I’m have to find an item in four different ways.

At first when I saw the code I cried abuse – it seemed to me that there bound to be a better way to do so without nesting four calls but after a while this solution seemed almost elegant.

What do you think?

The 7 levels of continuous integration

noreply@blogger.com (Dror Helper) — Fri, 20 May 2011 07:57:00 +0000

I’ve noticed that when other developers talk about “continuous integration” they do not always mean the same thing.
The following is an outline of the seven stages of continuous integration based solely on my own experience:

No Server, no automation - no problems
Have nightly build that run each day – at least we know that the project compiles
Started writing “unit” tests – now running as part of the nightly build
Created a build that runs on each commits – who broke the build?!
Added static code analysis and style checking to the build
Server Build, deploy & run the tests on several environments also used to deploy on testing (and production) environments
Everything is automated – Even Gui tests runs automatically on the latest code, you even got as far as testing the installer. Code is analyzed and results are sent by email. Nothing is done manually unless it is done only once…

These are my stages as I experienced them in several jobs – what are yours?

Happy coding…

QA and Development in Agile 2011

noreply@blogger.com (Dror Helper) — Tue, 17 May 2011 10:34:00 +0000

This Thursday (May19th) I’ll take part in a Panel at the “QA and development Agile” conference.

I’ve been asked to talk about unit testing, TDD, SCRUM and anything else agile – topics that you should be familiar with if you’ve been reading this blog.

There would be developer and QA tracks with very interesting sessions two of which by good friends of mine: Gil Zilberfeld and Lior Friedman.

I’ll be there all day long so if you’re there, come and say hi.

Don’t fix invisible bugs

noreply@blogger.com (Dror Helper) — Sat, 07 May 2011 18:45:00 +0000

Last week I conducted yet another code review. While looking at the code I’ve noticed a lot of lines similar to If(x != null) and if(y < 0) all over the code. These lines were not “business related” but were put in the code to make sure that proper inputs were given to the methods. Usually this is a good practice but further review showed that some of the code was checking for conditions that could not possibly happen. it meant that a lot of effort was given to creating code that checks for things that would never happen.

I’ve asked the developer why he written that code and he answered that it was put there to make sure that he handles a certain scenario properly. I’ve asked him when such conditions would happen and after thought he answered – never!

In that case - I said – please remove this code. At first he insisted that the code should stay there because: You can never know and because it was already written. I didn’t even dignify the 2nd remark with an answer but instead told him to write a unit test that shows that the code was important and could save us from disaster. After a few tries he was convinced that there is no way to cause his methods to fail and that this code is not needed.

This is not a new thing, when I see a fellow developer over thinking some method or class I suggest that first he write a test. I try to make sure that all of teammates practice TDD (Test Driven Development) along other benefits writing the tests before hand guarantee that every lines written is needed. But even if you do not writes your tests first and you find yourself asking whether you need to write “that code” try writing a test before to show that there a problem there that need solving…

It seems that code coverage goes both ways – it’s important to make sure that your code is well tested but if there is a piece of code that is not tested it could be because it would never run – and as such can be removed.

3 signs that you’ve been coding too much

noreply@blogger.com (Dror Helper) — Thu, 21 Apr 2011 08:10:00 +0000

Could there be such thing as too much coding? From time to time I get reminded that there is more to the world than Visual Studio and highlighted text. Below are real stories that happened to me (sometimes more than once), causing me to ask myself – should I take a break?

Run in debug mode emailing

You’ve just tried sending an email by pressing F5
When a co-worker told me that he’s just used the “Run" from debugger” button to send an Email it made me laugh. only to do the same thing after a few months…

I guess my brain was wired to press F5 to “execute” – stupid brain.

Compiling word documents

In my pre-Resharper days I was used to compiling my code every few lines as a basic “sanity check” it was for my code what quick save is for games. it became such a second nature that a few times after I’ve finished writing a paragraph in word I’ve tried to compile it by pressing ctrl + shift + B.

Proper coding standards in text files

This one is new. I get to write comments to document my code. a few days ago after writing a line of documentation I’ve noticed that I’ve used Pascal case TheEntireTimeAndTheWierdThingIsThatIWasAbleToReadItAtLeastOnceBeforeNoticing.

Conclusion

Sadly these is not a fictionally post – it happened to me and might happen to you. And I know that I’m not the only one – so if you have stories of strange things that happened to you or your “friend” – please leave a comment.

by Pedro Moura Pinheiro

Happy Coding…

Testing right by testing the right thing

noreply@blogger.com (Dror Helper) — Mon, 04 Apr 2011 14:18:00 +0000

Before answering questions about unit testing I usually tend to ask some questions to get the broader picture – especially if the question sound strange.

Such question was asked by a teammate – he wanted to know if he can replace the behavior of a fake object while still calling the method replaced. This sounded a bit strange to me – either you want to fake an object or you don’t so I asked him if he happens to test the functionality of the same object he’s faking – he answered that no but he needs the method to run in order for the test to pass.

At first he insisted that he wants to test if a problem report in the system was closed twice as so he needs to count the times that the close method was called while still calling it. Next I asked him how does the user notice the issue, does our user care that he closes the report twice? obviously the user does not care. After further inquiry I manage to find that if a close operation is performed on an already close report an exception is thrown and the user does not get notification for the end of the running process. After we cam to that conclusion he managed to write a simple unit test that checks whether the user is notified in no time.

In retrospect I could have told him how to solve the issue he had using our Isolation framework of choice – the result would have a been a poorly written, fragile test.

by DHDesign

Happy coding…

DSL presentation at the local Software Craftsmanship group

noreply@blogger.com (Dror Helper) — Thu, 24 Mar 2011 18:30:00 +0000

A couple of days ago I gave a talk at the local Software Craftsmanship group on the subject of Domain Specific Languages (DSL) and fluent interfaces. After the session I prepared an exercise for the audience:
Create a fluent interface for an online shop that calculates discounts based on customer and purchase information.
I gave a list of use cases and waited to see what would happen:

VIP customer get 15% discount on all purchases
Buying product A would give you 10% discount on product B
Preferred and VIP customers can buy 5 + 1 of a specific product
All customers can get 20% off purchase using specific coupon
If amount of purchase > 100$ customer is entitled for 10% discount.
If customer have purchased > 100$ the last three months upgrade him to VIP
On the customer’s birthday he’s entitled to 50% discount
All customers living in New York can get up to 25% off all purchases

I was expecting API along these lines:

RuleEngine.CustomerOfType<VIP>().GetDiscountOf(15);

The group was divided to teams of 2-3 developers choose a programming language and started working on my exercise. The first thing I’ve noticed is diversity in programming languages – C#, Java, C++ (on Linux!), Python and Ruby were used.
After a while it has become clear that the room was divided into two main groups of thought. Some teams started to design the object model required to solve the problem while other teams started implementing the rules and created the fluent interface from the required rule. This made me think about upfront design vs. iterative development. No one managed to complete the entire exercise but the teams that choose to design up front managed to cover less rules than the teams that created the rules one by one.
It was fun watching teams designing an API and then finding ways to create the API they wanted. I saw some interesting implementation ideas that were very different from what I had in mind in a good way.
All in all it was a good meet-up I can’t wait for the next time.

Domain specific languages

Update
The session (in Hebrew) can be viewed here - thanks to Uri

SCIL.DSL from Uri Lavi on Vimeo.

Advice for the newbie developer

noreply@blogger.com (Dror Helper) — Thu, 17 Mar 2011 12:56:00 +0000

Every developer was a newbie once. It doesn’t matter if you’re fresh out of college or been developing software for 10 in this line of work you get to be the newbie from time to time – whenever you learn a new technology or programming language and to some extent whenever you start working in a new place.

Lately a new member has join our team. Her is a capable developer with years of experience under his belt, he is also completely new to the .NET world. Luckily he has the right attitude and he’s willing to learn everything from scratch - fast.

the following is my advice to the software developer who wants to learn created from observations of the last few days:

Admit that you’re a newbie

This on isn’t trivial – in order to become a seasoned developer you have admit that you’re not there yet. This becomes harder as you become a more experienced developer. although you can use old knowledge in order to learn new stuff quicker more often than not you need to start from the bottom. a seasoned C++ developer would probably learn C# quicker than someone who never wrote a single line of code but it does not mean he automatically knows everything.

Be willing to leave your comfort zone

This is the prerequisite to learning new things. You might be used of doing things using tools and practices that does not apply to the new technology. Instead of forcing your beliefs and methods where they don’t belong you need to learn new ways of doing things. The plus side is that you might learn something that would change the way you think.

Find a mentor

Although this point is not mandatory, it helps when there’s someone to learn from. Find your mentor and ask him questions. It could be your team leader, another team member or your friendly neighborhood architect. It doesn’t matter as long as he’s willing to teach you. He would help you avoid the same problem he already solved and teach you new tricks specific to your project sometime without even noticing.

Keep an open mind

Change is hard, Learning new stuff is hard. Try not to be the obstacle to your own learning. It’s easy to explain why your old way of doing things is better than others and what’s wrong with everything around you (and that prices were reasonable, politicians were noble and children respected their elders). The point is that you need to learn – so why not try something new, the worst that would happen is that you learn not to do it anymore.

Don’t take anything for granted

Ask questions, not just to learn but to understand why things are done. Just because you’re new it doesn’t mean that you cannot teach as well. People get used to doing things a certain way that might be changed due to a fresh perspective.

Conclusion

That’s my thoughts on the subject – I hope it helps the next time you have to learn something new…

How I Learned to Stop Worrying and Love the Coding Convensions

noreply@blogger.com (Dror Helper) — Wed, 09 Mar 2011 10:22:00 +0000

Can you spot the difference between the following two code snippets?

Exhibit #1:

public class MyClass
{
    public int MyFunc(int x, int y)
    {
        return x + y;
    }
}

Exhibit #2:

public class MyClass{
    public int MyFunc(int x, int y){
        return x + y;
    }
}

If you have some programming experience you might recognize the two styles. One of which common in your projects and the other looks strange and might even cause you a slight discomfort or bad feeling at the pit of your stomach. Some software developers have been arguing about which is better for as long as I can remember and to tell the truth I was one of them until recently.

I work mostly in C# and the majority of projects/demos/tutorials out there use the first convention. I used to argue that it’s better because it makes the code more readable and besides that’s the Visual Studio default and if it’s good enough for Microsoft it’s good enough for me. Then I got to my current employer where the official coding standard defines option number 2 as well as other conventions and it was hard. Each time I glanced at my code I had the urge to re-format, it made me feel “dirty”. After a while I got used to the new curly brackets location but it still felt wrong to me. One of my responsibilities is to make sure that all of the teams projects follows the official company’s coding specifications some of which I don’t fully agree with.

I’m a fan of this developer’s life podcast and yesterday I heard the latest show Obsession where Scott and Rob talk to several developers about their obsessions and than it hit me – the feeling I have whenever I see code that formatted “wrong” is my little OCD (obsessive compulsive disorder), it’s one of the obsessions I picked up on the way, I need to code to be “right”, similar behavior can be found when developers argue what is better – camel-case or Pascal-case, spaces or tabs, VB.NET or C# and so on. Many of these arguments are valid but sometimes we just miss the point, just because we feel good/bad with something doesn’t mean that it’s right it just mean we’re more comfortable with it and that’s ok.

As for coding standards there is a valid reason they’re in place – we want all of the company’s source code to follow the same rules. An important goal – even at the price of making you feel good about how the code looks.

One final note – this can only go so far, if the rules make the code less readable and the developers less effective – you should make an effort to change them.

Happy coding…