Jomo Fisher -- Sharp Things : Code Quality

Correct by Construction in F#

Jomo Fisher — Tue, 22 Apr 2008 22:56:00 GMT

Correct by Construction in F#

Jomo Fisher—a theme in the design of the F# language is that problems in the code are revealed as compilation errors. Consider this C# code which is used to compose a courteous letter to a customer:

enum Courtesy { Mr, Ms, Dr }

class Customer {

public Courtesy Courtesy { get; set; }

public string Name { get; set; }

}

class Letter {

public string Introduction { get; set; }

public string Body { get; set; }

}

static Letter Correspond(Customer customer, string message) {

switch (customer.Courtesy)

{

case Courtesy.Mr:

return new Letter { Introduction = "Mr. " + customer.Name,

Body = message };

case Courtesy.Ms:

return new Letter { Introduction = "Ms. " + customer.Name,

Body = message };

}

return null;

}

This compiles without errors despite having some problems (can you spot them?)

I want to stop now and claim that I’m not picking on C# which is a wonderful language. It’s just that I need to compare F# to something in order to illuminate my point and I happen to know C# pretty well.

Now, transliterate the code above into F#:

#light

type Courtesy = Mr | Ms | Dr

type Customer = {

Courtesy:Courtesy

Name:string

}

type Letter = {

Introduction:string

Body:string

}

let Correspond(customer,message) =

match customer.Courtesy with

| Mr -> {Introduction = "Mr. " + customer.Name; Body=message}

| Ms -> {Introduction = "Ms. " + customer.Name; Body=message}

| _ -> null

Compiling this gives a warning on the last line:

error FS0043: The type 'Letter' does not have 'null' as a proper value.

In C#, objects are allowed to be null by default and your code is responsible for handling the possibility of nullity everywhere. F# objects are not allowed to be null and, except in a few special cases such as interoperating with non-F# code, you can assume that object instances aren’t null.

So the caller of the Correspond function need not worry about receiving a null Letter instance and I can just delete the last line:

let Correspond(customer,message) =

match customer.Courtesy with

| Mr -> {Introduction = "Mr. " + customer.Name; Body=message}

| Ms -> {Introduction = "Ms. " + customer.Name; Body=message}

Now I get a warning:

warning FS0025: Incomplete pattern match on expression. The value ‘Dr’ will not be matched

This is an easy mistake to make: I forgot one of the cases in the Courtesy enumeration.

An aside on pattern matching: If you code in F# you’ll find yourself using pattern matching for a significant amount of the logic in your program. It’s far more than just a synonym for switch. It can do complex matching against just about any type of object. This, combined with completeness checking, helps eliminate a large class of bug.

Here’s my final corrected code:

let Correspond(customer,message) =

match customer.Courtesy with

| Mr -> {Introduction = "Mr. " + customer.Name; Body=message}

| Ms -> {Introduction = "Ms. " + customer.Name; Body=message}

| Dr -> {Introduction = "Dr. " + customer.Name; Body=message}

This idea that F# should lead you to write code that is correct by construction is not just about the features I mentioned above. Its fundamentally weaved through the language. Take a look at how casting works for another example.

Honestly, it took me some time to get used to. I particularly struggled with the non-nullity of object instances. I was used to being able to smuggle the special “null” value around without changing my code to accommodate it. I realize now I was just sweeping a potential problem under the rug.

This posting is provided "AS IS" with no warranties, and confers no rights.

Leaky Functions\Barrel of Bugs

Jomo Fisher — Wed, 16 May 2007 22:55:00 GMT

Jomo Fisher--Pop quiz. Consider this function call in C#:

a = MyFunction(b);

What information is exchanged between the caller and the function? When is the information exchange done?

It would be nice if the answer was:

MyFunction takes value b and returns value a. When the function finishes no more information is exchanged.

There are several reasons information may leak out of a function call and all of these reasons can cause subtle bugs in your code.

Let me start with the granddaddy of function leaks to illustrate my point:

static int counter = 0;

static int MyFunction(int v) {

++counter;

return v;

}

This is good old-fashioned global data. I think it’s well accepted that globals can cause bugs so I won’t go into that. My point is that there is a family of function leaks and to a greater or lesser degree all these leaks can cause subtle bugs in your code.

Here are some more leaks that have personally caused me grief in the past.

Reference Parameter as Value Assumption

Here, I want to pass a point to a function.

Point pt = new Point();

pt.X = 1; pt.Y = 1;

SetPixel(pt);

class Point { public int X; public int Y; }

static void SetPixel(Point pt) {

// Do some work...

pt.X = 0;

}

Did you see that? Whoever wrote SetPixel decided they could change my Point instance behind the scenes.

Well, at least the damage is done once the call to SetPixel is complete. There’s a good chance of finding this bug quickly.

What about this variation?

class Graphics {

Point lastPixelSet;

public void SetPixel(Point pt) {

// Do some work...

lastPixelSet = pt;

}

Now SetPixel is holding my point and can change it even after SetPixel has returned.

Collection Parameter as Value Assumption

Things get worse for collections:

static void WriteList(List<string> list) {

// Do some work.

list[5] = "I like ponies.";

}

You could try changing the signature to take IEnumerable, but trouble can find a way:

static void WriteList(IEnumerable<string> list) {

// Do some work.

if (list is List<string>)

((List<string>)list)[5] = "I like ponies.";

}

Return Reference Leaks

Function callers can also cause problems:

Optimizer o = new Optimizer();

Point p = o.FindMaxima();

p.X = 0; // Yikes! This changes private data held by Optimizer.

class Optimizer {

private Point maxima;

public Point FindMaxima() {

return maxima;

}

A Patchwork of Fixes

So we’ve identified a coding pattern that can cause subtle bugs, is there anything we can do? One approach people take is to copy structures at function call and return boundaries:

SetPixel(pt.Duplicate());

class Point {

public int X;

public int Y;

public Point Duplicate() {

Point d = new Point();

d.X = X;

d.Y = Y;

}

There are some problems with this. First, who is responsible for making the copy? Is it the caller or the function? If you don’t have a rigorous rule for your code then often you end up with two copies or no copy at all. Second, all those Duplicate calls clutter your code and obscure its intention. This is a maintenance problem.

For collections, there’s a built-in solution that will let you wrap your collection in a read-only façade:

List<string> contacts;

IEnumerable<string> GetContacts() {

return contacts.AsReadOnly();

}

This is well enough if you remember to do it. You could do a similar thing for your own non-collection classes, but then every class would need another separate class to act as the read-only reference.

An Elegant Solution

You can find a far more elegant solution in the .NET String class. Try this:

string s = "abcde";

DoSomething(s);

static void DoSomething(string s) {

s[3] = 'x';

}

Does this modify the string from the calling function? The answer is no. In fact, this won’t even compile because there’s no setter implementation on the indexer. This is important:

There’s no way at all to change a .NET string once it’s been created.

The string class is immutable. You can verify yourself by right-clicking on the string and selecting Goto Definition.

This means that any function that takes a string as a parameter or returns a string has an explicit contract that the function can’t leak through that string reference.

An Immutable Point

Here is the Point class implemented as immutable:

class Point {

public int X {get; private set;}

public int Y {get; private set;}

public Point(int x, int y) {

X = x;

Y = y;

}

public Point SetX(int x) {

return new Point(x, this.Y);

}

public Point SetY(int y) {

return new Point(this.X, y);

}

Now, you’re free to pass these Points around without copying them and without worrying about leaky functions. It’s true that you have to copy the point to change it, but I think the fact that string is a successful immutable class means that other immutable classes can also be successful.

I have a similar immutable list implementation which I will save for a future blog entry.

This posting is provided "AS IS" with no warranties, and confers no rights.

Code Quality Tip #3: Switch Gears, Eat your Dogfood

Jomo Fisher — Tue, 26 Jul 2005 19:56:00 GMT

Jomo Fisher--Recently, the whole C# product unit took a week off from our regular work to do some App Building. We split up into teams and competed to see who could build the coolest application and find the most bugs in VS 2005. Given where we are in the schedule we’re trying hard to reveal remaining hidden issues.

This leads me to code quality tip #3: Be aggressive about using your own software. Eat your own dogfood. This is a great way to put yourself in your customer’s shoes and to find bugs that have complex repro steps.

Here’s how App Week went for my team:

Day 1: Our team is two QA, one PM, three DEV (counting me). We meet and decide what to work on. Some of the ideas we put on the table:

· A C# compiler for the Lego Mindstorm.

· A tool to offload mathematical operations onto GPU (recent commodity video cards can push 40+ GFlops and they’re getting faster at better than Moore’s Law rates).

· A video game emulator.

· A Real Time Simulation video game (like Age of Empires).

We decide democratically to go with the video game and name our team War<Worlds>. This wasn’t my first choice, but I have an interest in AI and my vacation starts on Wednesday so I shouldn’t push for something that I’m not going to be here to support towards the end.

Day 2: We spend several hours sitting in a room trying to decide on interfaces for our game. Mostly this was a waste of time—we should have delegated this job to one person and accepted their decisions. Eventually we do pick a person to design the interfaces and he’s got something good early on Day 3…

Day 3: My coding on the AI begins in earnest. I’m a fan of TDD so, naturally, I want to set up a Team System test project. I really think the Team System Test framework is great—it’s solid and has integrated code coverage. The problem comes when we add the test project to source control. Once the project is under source control we can’t open it anymore (it doesn’t matter wither its Team System source control or Source Safe). Great! That’s a bug that would have been tragic to ship. By the end of day 3, team War<Worlds> has found three killer bugs and a bunch of annoyers and we’ve pulled into first place.

Day 4: More coding. I get to the point where the AI is functional but not likely to win any games. Unfortunately, I have to leave for vacation in the morning.

On Friday, while I’m boating on Diamond Lake with my family team War<Worlds> goes to demo the game for the rest of the PU (yes, they manage to get a minimal, but functional RTS going in five days). We enter the demo with a commanding lead in terms of the bugs that we’ve found. Sadly, the demo goes poorly and we lose points. We end up coming in second overall.

App Week was new to me because the VSCore product unit (home of my last team, MSBuild) didn’t do them. Now that I’ve seen one in action, I’m a fan. It was a great opportunity to switch gears and look at VS from a new perspective. I got to work and know some folks that I wouldn’t normally have spent much time with.

This posting is provided "AS IS" with no warranties, and confers no rights.

See Tip #2: Use the Whole Test-First Whale

Hack the Build: Use the Whole Test-First Whale

Jomo Fisher — Wed, 25 May 2005 19:51:00 GMT

Jomo Fisher—

Try lots of things to improve quality. Keep doing what works, stop doing what doesn’t.

Writing code with Test-Driven-Development (TDD) takes about 30% longer than writing code without it. This was my experience on MSBuild. Still, as I noted here and here, I’m a fan of TDD. Code quality tip #2 explains why…

Tip# 2: Take Maximum Advantage of Developer-Written Tests

Subsistence hunters use every part of their kill. This makes sense because it’s hard to catch a whale. If you expend that kind of effort, you need to maximize your return. If you don’t then you’ll freeze all winter while your neighbor down the coast is toasty warm next to their blubber-oil stove.

I don’t think of TDD as just a goal in itself. I think of it as a platform for a set of code-quality drivers. What follows is a set of ideas for how to get the maximum use out of your developer-written tests. We used all of these, with success, on MSBuild:

Everyone Shares the Tests—We checked the test source code into source control alongside the shipping production code. Everyone worked with and contributed to the same set of tests. As a developer, this allows you to create features that are virtually impossible for your well-intentioned team-mates to break.

You Can’t Check in until All the Tests Pass—In addition to using the GUI test driver for development, we have a single batch file that reports a failure if any tests are failing. Before you can check it, you have to pass the whole battery of tests. This keeps the code in source control pristine.

Drive Up Code Coverage—With ideal TDD you should be able to hit every line of code in your product with unittests. In practice, this turned out to be more like ~87% of the code for MSBuild. You can judge the relative health of your unittests (and your TDD process in general) by looking at code covered by the unittests. Try this: set a break point on every line in one source file, run your unittests under the debugger. Every time you hit a break point, remove it. When you’re done, the remaining break points indicate unittests that you’re missing.

Every Bug Has a Test—When fixing bugs, first create a test that fails. Then fix the bug and see the test pass. Bug regressions (bugs which return after they’ve supposedly been fixed) are very expensive. If you use a bug tracking system that assigns a number to every bug, consider sticking this number in the method name:



[Test]
public void Regress99999_EjectedCDInjuresUser() {...}

This way, you can always track the test back to the original bug that it was supposed to address.

Refactor Mercilessly—People sometimes use a word called “churn”. It’s a derogatory term for changing a lot of code at once. Thing is, changing a lot of code is often the right answer. Avoiding a needed refactoring can cost you more down the road. Once you have a good corpus of unittests, take advantage and refactor whenever it makes sense. If you’re a manager or team-lead, let your team know it’s OK to refactor as much as they need to.

Mutation Testing—Think of unittests as an immune system for your code. If there’s a bug in your code, then a test should fail. The idea behind mutation testing is to intentionally inject a bug in your code and then run unittests to make sure at least one fails. There are plenty of ways to create bugs in your code. For example, if you have this:

	
if (condition) {...}

Then replace it with,

	
if (condition && false) {...}

Did a test fail? If not, add a unittest that does fail. If you can’t, the code is probably redundant and can be removed.

We automated the process of systematically injecting bugs into the code and running unittests. Our solution used a hand-written C# parser to generate the mutation set. I haven’t tried it, but there’s a free tool called Nester which is supposed to automate this for you for C# files.

See Tip #1: Code Reviews

This posting is provided "AS IS" with no warranties, and confers no rights.

Hack the Build: Code Quality and Test Driven Development at Microsoft

Jomo Fisher — Mon, 16 May 2005 19:12:00 GMT

Jomo Fisher--I mentioned a while ago that MSBuild team uses Test Driven Development (TDD). Afterwards, several people expressed interest in the general development process at Microsoft. Code Quality is an area that I care deeply about and I’ve tried a lot of stuff over the years to improve my own personal development process and the process of the teams that I’ve worked with. If there’s one fundamental lesson that I’ve learned it’s this:

Try lots of things to improve quality. Keep doing what works, stop doing what doesn’t.

This lesson implies that two things need to happen:

(1) You need a stream of ideas to try.

(2) You need to be able to recognize when something is working and when it isn’t.

The second part depends a lot on the dynamics of your team, your company and the industry you serve. What works for one team may be fundamentally broken for another. This is a balance that is unique to every development shop and so it’s hard to make generalizations about this.

For the first part, however, I think we can help each other. I have some ideas that have worked well for the teams that I’ve worked on. In this post and in future posts I’ll share these ideas, along with the pitfalls we ran into. If something sounds good to you, give it a try. Also, if you’ve tried something that has worked well for your team, I’d love to hear about it. I should mention that very few of these ideas are originally mine. These are mostly other people’s ideas that I’ve picked up over time

Without further ado, here is…

Tip #1: Do Codereviews Before Checking In

This tip assumes your team uses some sort of source control. I know this isn’t true for every team, but I think this is valuable enough to mention anyway.

Here’s how this works on my team. Once a developer is done writing a chunk of code, he asks another developer for a codereview. The two developers sit down and go through the changes line by line talking about the impact of the change. We use a tool called WINDIFF.EXE to help with this process. One way to use WINDIFF is to create two directories, one with the before code and one with the after code. Then call WINDIFF like this:

WINDIFF c:\before c:\after

The code review process has lots of dials that you can turn to suit your team. Here are the dials along with my own preferred setting.

When to do Codereviews—Do you review for minor fixes or do you save them for big, architectural changes? I like to get reviews for every checkin. The reason is that I view a codereview as a learning and communication opportunity rather than just a quality gate. Also, when you’re working in larger teams there’s a huge benefit to keeping the checked in code as high-quality as possible because every flaw that makes it into source control gets multiplied by the number of developers that will eventually experience that flaw.

Picking a Codereviewer—Some shops like to let only the senior developers do the reviewing. My preference is to let everyone review code. The reason is that this can be a learning process for both reviewer and reviewee. While a senior developer may catch more bugs, a junior developer will get exposure to how different areas of the code work.

Authority—Who gets to make the final decision when there’s a disagreement? This part has to be up to your team. To me, the healthiest code reviews are those where the codereviewee is able to detach his ego from the code he has just written. This can be pretty hard sometimes. When I receive a codereview, I try to accommodate the reviewer’s feedback as much as I can and save my pushback for the areas that I’m most passionate about.

Detail—How much detail do you get into? Codereview feedback can vary from brace and comment placement to sweeping architectural issues. When I’m receiving a codereview, I find the best use of time is to just accept and agree to fix nitpicks so that we can focus as much time as possible on architecture. When I’m the reviewer, I try to focus as much time as possible understanding whether the change is structurally sound. If I have nitpicks, I mention them in passing and try to move on quickly.

Finishing—When is the codereview done? When I receive acode review, I like to send the reviewer an email about how I fixed each issue. I also give them the option of returning for a follow up codereview.

I’d be interested in hearing from people who’ve had positive or negative experience with codereviews. What worked for your team?

See Tip# 2: Take Maximum Advantage of Developer-Written Tests

This posting is provided "AS IS" with no warranties, and confers no rights.