jaybaz [MS] WebLog : Development Practices

properties vs. fields... again

jaybaz_MS — Fri, 09 Feb 2007 00:14:00 GMT

Eric Gunnerson just posted Properties vs public fields redux... It's no secret that I agree with Eric whole-heartedly on this matter. I've posted about this before as well: http://blogs.msdn.com/jaybaz_ms/archive/2004/04/29/123333.aspx. Fundementally, the problem is one of "speculative generality", where you are writing code today that has no use, because you think that it might be needed sometime in the future. Of course, since you can't predict whether it will be used, and you can't predict how it will be used, your guesses are wrong most of the time. That is, most public properties are trivial forever.

It's interesting that the strongest objection some people have is that it requires a rethinking of some of the common naming conventions to adjust appropriately. Such a minor issue, and so easily resolved.

Since my original post, I've come across a couple other reasons why the "always use properties" guidance is broken. Specifically, if you are correct that you may need to maintain binary compatibility while changing implementation, then you'll probably need it in other places:

1. Constructors lock you in to a type. If you really want binary compatibility, you should stop providing ctors, and start providing factory methods:

public class MyClass

{

MyClass() { }

public static MyClass New() { return new MyClass(); }

}

The purpose, of course, is to allow you to return a different object type that derives from MyClass in the future, while maintaining binary compatibility.

2. Types lock you in to a type. If you really, really want binary compatibilty, you should stop providing types at all, and start dealing only with interfaces:

public interface IMyInterface

{

void F();

}

public class MyClass : IMyInterface

{

MyClass() { }

public static class Factory

{

public static IMyInterface New() { return new MyClass(); }

}

void IMyInterface.F()

{

// ...

}

Now, I look at this code, and I think I'm writing a lot of lines for nothing. That is, in my domain, this kind of generality is unnecessary. That's why I don't generally use factories, interfaces, or properties. I consider them to be kin.

There are probably some other constructs that go along with these, for speculative generality. These are just the 2 that come to mind.

If you still believe that you need to use properties in the trivial cases, I hope you will examine these constructs and consider them seriously in your own code. I suspect you should be choosing all or nothing.

random debugger tip: catching COM exceptions

jaybaz_MS — Thu, 18 Jan 2007 03:25:00 GMT

I was cleaning out some old mail and came across this tip. You can tell it was a long time ago, because it really only matters if you're writing COM objects, something I haven't done in a long, long time.

Some parts of Visual Studio use COM as a layer to handle cross-thread calls and enable cross-machine remoting. One of the downsides of this technology is that a COM exception in a server is caught by COM and converted to an HRESULT. That HRESULT is harder to notice & catch in a debugger than the original exception.

However, there is a registry key that will change this behavior. When this key is set, the exception is passed through normally, and can be detected & debugged through normal mechanisms.

The key is:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole]
"IgnoreServerExceptions"="Y"

(The real reason I'm blogging this is so that I can find it in the future if I ever write COM again. :-))

The next Accidental Difficulty in software

jaybaz_MS — Fri, 13 Oct 2006 21:13:00 GMT

First, go read this article by Joel: Book Review: Beyond Java. He mentions this list, of great advances that have address some accidental difficulties in software:

Assemblers
Algebraic languages (including Fortran)
Structured languages (Algol-60 and C)
Declarative languages (including SQL)
Memory-managed languages (including Lisp, VB, and Java)

First, I'm disappointed he didn't list C# next to Java in #5. By no means did Java (or VB) invent automatic memory management (garbage collection). Perhaps you would give those languages credit for bringing managed memory to the masses, but in that case, C# belongs on the list.

I remember a very interesting discussion here a couple years back, about this very topic. Cyrus was saying that at some point we'll expand the domain of the Garbage Collector to non-memory entities, like files, database connections, etc. Sure, figuring out of it's time to dispose of those things is hard, but computers are getting more powerful, and we'll eventually build that in to our programming systems.

So, think of all the times you have written 'using' statments in your code, and consider the possibility of a language that made them unnecessary.

Finding the correct source

jaybaz_MS — Mon, 21 Aug 2006 22:57:00 GMT

From a previous comment:

> A copy of the source tree that exactly matches that test VS.

Why IDE unable to keep track versions of sources for me ?
Why not embed meta-information in PDB's on how and there to retrieve correct source file version ?

Actually, it does. In VS2005, the debugger team added two features along these lines. The first is "source file checksums", described here: http://blogs.msdn.com/andypennell/archive/2004/06/29/169002.aspx

The second is Source Server, described here: http://msdn.microsoft.com/msdnmag/issues/06/08/UseTheSource/default.aspx

However, the problem that I'm dealing with is a little more complex (and much less likely to occur in the wild). On my dev machine, I need a copy of Visual Studio and the sources that built it, so that I can modify the sources, build one component, and try it out. If the sources I start from don't match my copy of VS exactly, then I can't know which changes in behavior are due to my changes. Furthermore, if interfaces have changed, then the product is likely to stop working entirely.

Does that explain things?

slack

jaybaz_MS — Wed, 20 Apr 2005 03:56:00 GMT

There was some discussion here about the book Slack. For months I have haven't had any time to participate, or even observe in such discussions. But this discussion appeared a few days after the Beta 2 work dropped off. I was spending 4+ hours each day in meetings to discuss Beta 2 bugs; it was hard to do anything else. It worked out well, that my first slack in months & the discussion about Slack appeared at the same time.

In the last two weeks I've been practicing slack. I've been going through my backlog of stuff.

The first few days I told myself that I really needed the break, just to see what email I hadn't read.

Then I got to the point where all the "urgent" stuff was taken care of, and I took a couple days to relax, do non-urgent (but still important) work, enjoy the beautiful weather, and see my family in the evenings.

Pretty soon I started feeling uncomfortable. I was worried that I was underperforming, that I had lost my motivation, that I was not doing a good job, that I was just coasting.

I reimaged my dev machine. I cleaned & organized my office. I looked through all my old mail that I had never responded to. The oldest was a year old, and I finally gave it a response.

Then I made the connection. This stuff is important, even though it isn't urgent. I should arrange my life & my schedule so that I usually have time to do these things.

I still have a lot to learn about doing this. I haven't managed to get into any exercise habit yet, like yoga or bicycling. I haven't managed to actually take off from work to go sailing.

What I'm doing these days

jaybaz_MS — Fri, 28 Jan 2005 21:52:00 GMT

Gee, this blog has been pretty quiet. Why? Could I have lost interest in the connection with all the C# developers in the world? No!

My responsibilities have drifted somewhat, to areas that make less sense to blog about.

Dev Lead

I'm the development lead for the C# editor, which means that my team creates C# Refactorings, formatting, intellisense, colorization, etc. That's where the most interesting blogging comes from.

How do you write your code?
How does this feature suit you?
Here's how we fixed this bug.
Here's an idea for a way to write some cool code.

“Box” Dev

But I'm also responsible for a chunk of the operations of the C# Product Unit ("VCSPU"). As we get closer to shipping Beta 2, I spend more & more of my time on these areas. That means things like:

Incoming triage for the C# editor and the debugger.
Setting the "bug bar" for VCSPU
Applying the bug bar to VCSPU bugs, as the bar changes over time
Looking for any risks that could cause us to miss goals.
Bean counting:

how many bugs do we have?
How many do we expect to find in the next weeks?
How many of those do we think we'll fix?
How quickly are we fixing bugs?
When will we be ready to ship?

Reporting status / plans / progress to all the devs in VCSPU
Increasing or reducing pressure on the VCSPU dev team, to balance productivity, morale, and quality of work

I do this as the representative of VCSPU Dev, in concert with a rep from QA (Kartik) and PM (Shaykat).

Starting Monday, we enter VCSPU Ask Mode. This means we meet every day to talk about each of the bugs we’re thinking about fixing, to make the final decision on each one.

Ask Mode forces everyone to start thinking about shipping the product (in this case, Visual Studio 2005 Beta 2). It helps us get serious & raise the bar. Because every bug now takes a bunch more time to process, we fix fewer bugs, effectively raising the bar even further.

I imagine that talking about all the details of this process is much less interesting to my readers than the wild ideas that you’re used to hearing here.

Checkin process

I’m also responsible for the VCSPU checkin process. We use automated tools to build & verify every code change. We have racks of hardware running various automated tests on every checkin. It helps keep the daily build quality high, and helps the devs avoid the tedium of manual verification.

I don’t spend much time on it these days, as I’ve managed to delegate it through several layers (Kevin -> Abhijit -> Tom). Again, it’s not too exciting to blog about.

Reviews

It’s performance review time. In the winter/spring we focus primarily on career development, and less on actually performance evaluation. Each of my reports deserves the best work from me they can get. I need to spend a bunch of time talking to each of them about their performance, their career goals, and what we’re doing to help them grow. I also want to spend a lot of time talking to their peers to get feedback that helps them further improve.

This is perhaps a bit more interesting to blog about, but much of it is personal & confidential, so my fingers are sealed.

Personal

I’m exploring some new foods. Cultured, fermented, and natural foods. I’m also continuing on my quest for simplicity. While it may be interesting, it all appears on my personal blog, not here.

Future

As you can see, I’m pretty busy with a lot of stuff that just doesn’t seem to make sense to blog. But that should change in a couple months. We’ll probably start dreaming big, and bringing those dreams to blogs. I also hope to get my hands dirty with some code again, which means more nutty ideas about ways to write the stuff.

Stay tuned.

Thoughts on bit fields.

jaybaz_MS — Tue, 11 Jan 2005 17:09:00 GMT

In C there is a long tradition of using bit fields to store a collection of boolean values:

enum

{

TF_KEYWORD = 0x0001,

TF_MEMBER = 0x0002,

TF_IDENTIFIER = 0x0004,

TF_STRINGLITERAL = 0x0008,

TF_CHARACTERLITERAL = 0x0010,

} TOKENFLAGS;

DWORD dwTokenFlags = TF_KEYWORD | TF_MEMBER;

This tradition has been carried over to C#, which is my area of interest. The support for bit fields in C# is a little different than C++, but my opinion of them hasn’t changed.

Upsides:

Potetential performance improvements due to reduced memory consumption. If 'bool' takes 8 bits, and a bit flag takes one, the 8:1 memory saves could concievably have a significant effect on performance. Of course, without real measurements you don't really know.

Downsides:

They're hard to define correctly. For each value, I have to write a definition that gives it a single, unique bit. If I forget that I'm writing in hex, I get a difficult to diagnose bug.

[Flags]

enum TokenFlags

{

Keyword = 0x0000,

Member = 0x0001,

Identifier = 0x0002,

StringLiteral = 0x0004,

CharacterLiteral = 0x0008,

VerbatimStringLiteral = 0x0016,

}

Did you notice that two of these items are broken?

It's hard to add new ones. If I want to insert a new value in the middle, I have to renumber all the remaining items.

In the debugger it's hard to know what the values are.

The code to manipulate them is hard to write correctly and hard to read.

// this means "if either one is set"

if (dwTokenFlags & (TF_CHARACTERLITERAL | TF_IDENTIFIER))

// this means "if both are set"

if (dwTokenFlags & (TF_CHARACTERLITERAL | TF_IDENTIFIER) == (TF_CHARACTERLITERAL | TF_IDENTIFIER))

// unset this flag

dwTokenFlags &= ~TF_CHARACTERLITERAL;

If there are rules about which flag combinations are legal, it's hard to enforce.

You can't add a constructor to initalize the flags to a default.

You can't add useful methods for checking aggregate combinations of flags.

It's tempting to add unrelated flags in the same enum, and then hard to split them out later.

It's tempting to use a single bit for multiple meanings in different contexts.

enum NODEFLAGS

{

// Only valid when the node is a MODIFIERNODE

NF_MOD_ABSTRACT = 0x0001,

NF_MOD_NEW = 0x0002,

NF_MOD_OVERRIDE = 0x0004,

NF_MOD_PRIVATE = 0x0008,

NF_MOD_PROTECTED = 0x0010,

NF_MOD_INTERNAL = 0x0020,

NF_MOD_PUBLIC = 0x0040,

// Only valid when the node is a STATEMENTNODE

NF_UNCHECKED = 0x0001,

NF_GOTO_CASE = 0x0002,

NF_TRY_CATCH = 0x0004,

NF_TRY_FINALLY = 0x0008,

NF_CONST_DECL = 0x0010,

};

If you get more than 32 of them, you’re out of luck. We have a case in our code today with 31 distinct values. We’re worried that we may need to add 2 soon…. Yikes!

It’s easy to mix up two types of flags:

// Type flags

DWORD dwFlags = TF_CLASS | TF_PUBLIC;

// Member flags

DWORD dwMember = MF_METHOD | MF_PRIVATE;

if (dwMember | TF_PUBLIC) // OOPS!

Potential for improved performance due to better memory alignment. Every time you access a bit flag, you have to execute multiple CPU instructions. 'bool' takes fewer instructions. This also means your code is smaller. Of course, without real measurements you don't really know.

A simple alternative: a class containing public 'bool' fields.

class TokenFlags

{

public bool Keyword;

public bool Member;

public bool Identifier;

public bool StringLiteral;

public bool Characterliteral;

}

TokenFlags tf = ...;

if (tf.Characterliteral || tf.Identifier)

This is easy to write and easy to understand. It solves most of the problems I listed above.

A hybrid approach: Encapsulated bit fields.

Hey, this is 2005, I should think about encapsulation. If I do some performance analysis & find that my application is too slow because of memory consumed by bools in Flags types that look like the one I showed above, it’s easy to convert:

class TokenFlags

{

enum Indexes

{

Keyword,

Member,

Identifier,

StringLiteral,

Characterliteral,

}

BitArray _bits = new BitArray(Enum.GetValues(Indexes).Length);

public bool Keyword

{

get { return this._bits[Indexes.Keyword]; }

set { this._bits[Indexes.Keyword] = value; }

}

public bool Member

{

get { return this._bits[Indexes.Member]; }

set { this._bits[Indexes.Member] = value; }

}

public bool Identifier

{

get { return this._bits[Indexes.Identifier]; }

set { this._bits[Indexes.Identifier] = value; }

}

public bool StringLiteral

{

get { return this._bits[Indexes.StringLiteral]; }

set { this._bits[Indexes.StringLiteral] = value; }

}

public bool Characterliteral

{

get { return this._bits[Indexes.Characterliteral]; }

set { this._bits[Indexes.Characterliteral] = value; }

}

Notice that this is source compatible with the ‘public bool’ approach, except if you pass one of the members with ‘ref’. If you’re worried about that, or binary compatibility, then use properties instead of public fields. But you know how I am about properties.

What about OO?

Good question. It’s taken me this far to consider OO.

It depends on the nature of the problem domain that you’re trying to work in, but there is surely an OO way, right?

For example, suppose we did:

interface IToken { }

interface KeywordToken : IToken { }

interface MemberToken : IToken { }

interface IdentifierToken : IToken { }

interface StringLiteralToken : IToken { }

interface CharacterLiteralToken : IToken { }

Well, I can write:

IToken token = ...;

if (token is KeywordToken)

F();

But now I can start taking code that was on the clients of the flags, and move it on to the tokens.

Before:

if (token is KeywordToken)

{

FooForKeyword()

}

else

{

FooForOthers()

}

After:

interface IToken

{

void Foo();

}

token.Foo();

Performance of 'for' vs. 'foreach'

jaybaz_MS — Thu, 23 Dec 2004 22:19:00 GMT

I saw someone ask if 'for' or 'foreach' is faster. I was surprised. My code is often slow when I first write it, but it's never something that could have been fixed by a microoptimization like that. So I wrote this:

In my code, I find that the most important thing for me to focus on is clarity. Writing clear code gives me the best chance of ever getting correctness, good performance, maintainability, and flexibility for future requirements.

If I try to directly build any of those, the loss of clarity means that I lose in all of them.

Regarding your specific situation, I would write the clearest way possible, then measure the real-world performance of my app, and then optimize where it matters.

It seems elementary to me, and yet I keep seeing folks trying to microoptimize like this. So I figured sharing the idea on my blog might be valuable to you, my audience.

'switch' in C#

jaybaz_MS — Mon, 15 Nov 2004 14:02:00 GMT

On Eric's blog, a discussion about 'switch' statements in C# & why they require 'break' inspired this post.

One of my favorite principles in the design of C# is that it forces you to be explicit when that removes confusion. The best example is the way that the language doesn't let you accidentally override a base method. If you don't explicitly say what you want, the compiler tells you about it.

In this case, the language is forcing you to be explicit again. Either you're done ("break") or you want to fall through ("goto"). You gotta say which one.

I don't worry too much about the syntax of 'switch' when I code. Instead, I try to have as few 'switch' statements as possible.

The OO way to do things is to use polymorphism to manage differences between cases, not a big decision statement. As soon as I find that I'm switching on the same thing twice, it's time to consider polymorphism. See ReplaceTypeCode*.

And the procedural way is to give each option a name (make them new methods). If I have a switch where the bodies of the cases get even slightly interesting, the whole switch gets out of control. So, at the very least, I want to Extract Method on each body.

In the ideal, I have relatively few switches with only trivial content.

We did something in Whidbey to help switch lovers. We’ll generate cases from an enum.

1. Type ‘switch’.

2. Hit TAB.
This will expand a code snippet with the skeleton of a switch statement. The expression to switch on will be highlighted as an entry field.

3. Supply your favorite enum-typed variable.

4. ENTER (to commit the expansion)

We spit out a ‘case’ block for each value in the enum.

We could have done more. We could have automatically spit out ‘break;’ as soon as you type case. I think that would have made people’s concerns about the superfluous ‘break’ in C# go away. When the editor takes care of it for you, it’s not a big deal. Maybe next time.

In general, I think it’s important that the language designers think about the editing context. If you intend your language to be edited “dumb” editor (like notepad), a semi-intelligent one (emacs, slickedit), or a very intelligent one (VS, eclipse), you would design differently. If you assume certain facilities in the editor, you can take advantage of them to make the language easier to read & easier to write.

Safely firing an event, Part 3

jaybaz_MS — Thu, 16 Sep 2004 23:52:00 GMT

Take another look at Safely firing an event. According to Grant, there’s another issue here. The JITter may optimize away locals in situations where you think want them for thread safety. So the recommendation to make a local copy is not as valuable as we had hoped.

Grant’s recommendation is to mark the event volatile:

public volatile event D SomeEvent;

void FireSomeEvent()

{

D temp = SomeEvent;

if (temp != null)

{

temp();

}

This problem just keeps getting worse & worse!

My conclusion: Use the empty delegate pattern, that I described in Safely firing an event, Part 2:

public event D SomeEvent = delegate { };

void FireSomeEvent()

{

SomeEvent();

}

It’s simpler, cleaner, less headache.

If I was going to design the language over from scratch, I would change the semantics of delegate invocation to say that if it’s empty it’s just a nop, instead of a crash.

Won't Fix or Postponed?

jaybaz_MS — Thu, 16 Sep 2004 17:42:00 GMT

In our bug database, when resolving a bug, you have to select a “Resolution”. Obviously you can resolve as “Fixed”. Other options include:

By Design - this isn’t a bug, we meant it to work this way.

Not Repro - you were mistaken, this bug doesn’t exist.

Postponed - this is a bug, but we won’t fix it this time. Will reconsider next version.

Won’t Fix - this is a bug, but we won’t fix it, not even in the next version.

There’s an interesting tension between Postponed and Won’t Fix. A Won’t Fix bug gets “lost” into history. (Actually, the bug database is always around & available to be queried, for all of eternity.) If you see a bug resolved Won’t Fix, you might worry that we’re dooming ourselves to shipping the next product in a broken state, too.

Near the end of each product cycle, we sit down to review all the Postponed bugs. It involves several of the leads from the team, and can take days. We’re looking for two things:

Bugs that we should fix next version / features that we should plan to do
Bugs that we should fix right now in the current version. Last chance! Pretty rare.

Then, shortly after the start of the next product cycle, we sit down to review all the bugs again. With a rough feature list & schedule in hand, we make sure that the bugs are assigned to the right person, that our feature plans take these bugs in to account, and that we have enough time set aside to fix the bugs we want to fix.

It’s a tedious & expensive process. And it’s often not very worthwhile. There’s a set of issues that we keep postponing every time. (Not many in C# IDE because it’s still pretty new, but on my old team this was pretty bad.) I think this is because these bugs really aren’t important enough to spend time on. We should put our time somewhere else.

When selecting between Won't Fix and Postponed, here's what I look at:

- If there's important information in the bug, like design decisions or the results of detailed analysis, then Postpone so we keep that information.

- If it's a real bug, but in a corner case that most people may not care about, I'll resolve it Won't Fix.

If we made the wrong choice (should have fixed it), we'll hear about it, from customers, partners, and dogfooders. Having the bug won't be an important part of our decision to fix it next time.

If we made the right choice (users don't really care), then we never have to think about it again.

- If it's a bug we know we want to fix next time, and there's a chance that we might forget to fix it otherwise, then Postponed.

- If the bug is something we won't fix without re-architecting the system, but is something we'll probably think about during the re-write work, then I resolve Won't Fix.

- If the bug came from ladybug, it nearly always gets Postponed. That because a customer has actually said they want the bug fixed. And because the sample set (beta users) is pretty small, the feedback should be taken seriously.

As you can see, I’m pretty hard core about marking as much Won’t Fix as possible.

Separating out unit tests

jaybaz_MS — Thu, 09 Sep 2004 21:33:00 GMT

This question came up on a customer chat today. It’s probably interesting to a wider audience, so I’m posting it here.

I'm currently doing TDD with NUnit. With the upcoming testing tools in Whidbey, how do you see the separation of tests from production code taking place? I'm curious about how best to develop tests and then not deploy them.

Any of the techniques for test separation that work in NUnit will continue to work with Burton Unit Testing.

You can put the tests under #if, and toggle the flag for release builds.
You can put the tests in a separate netmodule that you either alink in or don't. (New features in Whidbey make doing this easier, too.)
You can leave them in the assembly and ship them to customers, if that suits you.

You also have some 2 new options:

Put the tests in a separate "friend" assembly, using the System.InternalsVisibleTo attribute.
Use the new Whidbey feature that generates reflection-based wrappers for your classes. This allows you to "violate" accessbility settings within your unit tests.

Overall, the behavior of the unit testing in Burton and NUnit are very similar. If you're comfortable with NUnit, it should be very easy for you to make the transition.

A Factory pattern

jaybaz_MS — Wed, 01 Sep 2004 21:49:00 GMT

The idea popped in to my head, so I wrote it down. I’m not sure what it’s good for, but here it is:

class C

{

private C() { }

public static class Factory

{

public static C New()

{

return new C();

}

class Program

{

static void Main(string[] args)

{

C c = C.Factory.New();

}

How do you ship software?

jaybaz_MS — Mon, 30 Aug 2004 18:33:00 GMT

I surely don't need to tell you that we've been working on Whidbey for a while now. You probably wish we would hurry up & ship the thing. Me, too.

However, we still have some bugs left to fix. Most were found by our QA, but many came from Ladybug. Thanks for all of those.

We also got a whole lot of good suggestions via Ladybug. While we'd like to implement many of them, doing so is counter to the goal of shipping this product. So most of the ones I see, I resolve as Postponed. You get a comment from me saying "thanks, but no thanks". It'm bummed to write these comments, because I really want to get customers more involved with how we create our software. Your suggestions will be considered next time, though.

One thing that always happens is that you look at some feature and realize it has some serious problems. You need to rewrite a peice of it to really fix it right. It's really hard to say no on these, but the time has come. We gotta shut down.

One of the techniques we use is "staged goals". Suppose a team has, say, 100 bugs per dev, and we intend to hit 0 bugs in 10 weeks. To do that, we need to drop by 10 bugs / dev / week. So say we'll hit 70/40/10 bugs per dev, every 3 weeks. It's a good way to make sure you're on track.

Trouble is, we're not on track. We still have too many bugs to fix in the time that's available. We don't want to slip the product, but we do want deliver high quality.

Over the last week I've been combing through the bugs on my team. I read each one of them. I verify that they still exist in the latest build.

I also look for bugs that we can punt. (By "punt" I mean not fix in Whidbey.). Some get resolved "Postponed", which means we'll look at them again next time. One of the problems with Postponed is that there are some bugs we postponed last time (and the time before that). If we are postponing it repeatedly, we'll probably never fix it, and should resolve it "Won't Fix". That saves us the time spent reviewing it every product cycle.

There's another class of bugs I like to resolve as "Won't Fix". They're real bugs in the product, but it's not clear whether customers will ever run in to them, or care. So we Won't Fix, and assume that customers & dogfooders will tell us if they are annoyed. If it never comes up again, then we don't have to fix it.

We're also doing something usual. Sometimes we look at a bug and think "I'd like to fix this, but I wouldn't hold up the product for it." We're marking these bugs as "puntable". If the ZBB date slips, or we clear out our bugs faster than expected, or magic happens, then we'll fix these. But if things continue the way they're going now, we will resolve them before the ZBB date as Postponed.

As you can imagine, reading through every bug on my team is time consuming. There's some other stuff going on, too, hence not much time for blogging.

Some good feedback on the Range post.

jaybaz_MS — Fri, 20 Aug 2004 17:06:00 GMT

Dithermaster says “it's *much* easier to find out of they DON'T overlap” and proposes:

! ( (end2 < start1) || (start2 > end1) );

If we apply DeMorgan’s Law, we get:

(! (end2 < start1) && !(start2 > end1) );

And

(end2 >= start1) && (start2 <= end1);

Right? Even simpler. However, this idea disappears in my new code, as I do comparisons on the whole ranges, as suggested by Thomas Eyde:

Overlap(a, b){

return IsInside(a) || IsInside(b);

}

IsInside(a) {

return IsBetween(a, this.a, this.b) || IsBetween(a, this.b, this.a);

}

IsBetween(c, a, b) {

return a <= c && c <= b;

}

They bring different kinds of simplicity to the problem.

James Manning is the first to notice the bugs in my unit tests which allow bugs in my code to get by. Those are now fixed.

Mikeb notices that out-of-order parameters to the range can get you into trouble. I’m not sure which way to go on this. I decided that you’d be surprised that:

new Range(s, e).Start != s

so I went with the exception.

I thought pretty hard about whether Ranges should be constrained to IComparable types. I can’t think of any cases of ranges of non-ordered items, but I don’t want to make the constraint if I don’t have to. However, adding the constraint makes my code a bit simpler. In the end, I decided to take the constraint, solving the 99% case.

I also thought hard about whether ‘Overlaps’ should be a method on Range. It’s clear that ‘Contains’ should be, but I’m not sure where to put a method that acts on two peers. In the end, I decided to put the logic on an instance, and leave the static class for convenience of callers.

One thing I find myself desparately wishing for is operator constraints on generics. Then I could use ‘<’ and friends, instead of:

return this.Start.CompareTo(other) <= 0 && this.End.CompareTo(other) >= 0;

Luckily I only have to compare in 3 places.

The logic does seem to be much simpler now & easier to read. I’m happy about that.

Here’s the code:

class Range<T> where T : IComparable<T>

{

public readonly T Start;

public readonly T End;

// static void Swap<U>(ref U left, ref U right)

// {

// U u = left;

// left = right;

// right = u;

// }

public Range(T start, T end)

{

if (start.CompareTo(end) > 0)

{

throw new ArgumentException("Arguments are out of order");

// you may decide to just allow this & reorder, but I'm

// not sure that's a good idea.

//Swap(ref start, ref end);

}

this.Start = start;

this.End = end;

}

public bool Contains(T other)

{

return this.Start.CompareTo(other) <= 0 && this.End.CompareTo(other) >= 0;

}

public bool Overlaps(Range<T> that)

{

return this.Contains(that.Start) || this.Contains(that.End);

}

static class Range

{

public static bool Overlap<T>(Range<T> left, Range<T> right)

where T : IComparable<T>

{

return left.Overlaps(right);

}

And the revised tests:

Range<int> r = new Range<int>(1, 3);

Debug.Assert(r.Contains(2));

Debug.Assert(!r.Contains(5));

Debug.Assert(Range.Overlap(

new Range<DateTime>(new DateTime(1), new DateTime(2)),

new Range<DateTime>(new DateTime(1), new DateTime(2))

));

Debug.Assert(Range.Overlap(

new Range<DateTime>(new DateTime(1), new DateTime(3)),

new Range<DateTime>(new DateTime(2), new DateTime(4))

));

Debug.Assert(Range.Overlap(

new Range<DateTime>(new DateTime(2), new DateTime(4)),

new Range<DateTime>(new DateTime(1), new DateTime(3))

));

Debug.Assert(!Range.Overlap(

new Range<DateTime>(new DateTime(3), new DateTime(4)),

new Range<DateTime>(new DateTime(1), new DateTime(2))

));

Debug.Assert(!Range.Overlap(

new Range<DateTime>(new DateTime(1), new DateTime(2)),

new Range<DateTime>(new DateTime(3), new DateTime(4))

));

}

Thanks for all your ideas. J