Naming Direct Output Variables


In my series of Zero-Friction TDD tips and tricks, it’s time to look at naming Direct Output variables.


[TestMethod]
public void DoStuffWillReturnMessage()
{
    // Fixture setup
    string expectedResult = “ploeh”;
    MyClass sut = new MyClass();
    // Exercise system
    string result = sut.DoStuff(expectedResult);
    // Verify outcome
    Assert.AreEqual<string>(expectedResult, result, “DoStuff”);
    // Teardown
}

As you can see, I use the name result for the return value of DoStuff, and I always use that word, irrespective of its type or other circumstances. Whether you prefer result or another word is not important; the salient point is that by always using the same word, you save a context switch (because you don’t have to stop and think of a good name) and thereby incrementally increase your productivity.

Comments (3)

  1. I like to name the output variable "actualResult" because I feel it makes it more obvious for other readers that the actualResult needs to be compared with the "expectedResult".

  2. John Hilts says:

    Agree with BillW33