jaybaz [MS] WebLog : Visual Studio

Cutting "crashdump" support from the Visual Studio Debugger

jaybaz_MS — Mon, 31 Jan 2005 20:24:00 GMT

Scott writes about the proposal to cut crashdump support. Let him know what you think.

Personally, I think we should be much more aggressive with culling features, as we also add new ones. You end up with a cleaner product that is a better fit.

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.

Updated: jobs on the C# team

jaybaz_MS — Thu, 02 Dec 2004 23:38:00 GMT

We continue to hire in to the C# team. Here's the list of currently open positions:

http://msdn.microsoft.com/vcsharp/jobs

If you'd like to talk about jobs in C#, but nothing in that list suits you, don't let that stop you! Drop me a mail & tell me what you're interested in. Maybe we can find a fit.

'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.

Come work on C#

jaybaz_MS — Thu, 30 Sep 2004 23:55:00 GMT

I wanted to post a short note about all the different job opportunities available today in C#.

We have 3 areas of focus:

C# IDE (Refactoring, intellisense, etc. - what I work on)

C# Compiler (command line compiler + IDE integration)

Visual Studio Debugger (all languages, not just C#)

And we have 3 disciplines (greatly simplified)

Developer - write code

Tester - verify features + report bugs

Program Manager - communication/coordination + design

All positions are highly technical, and require someone who is able & motivated to everything it takes to satisfy our customers. If you're the right fit for any of these positions, I guarantee that you'll have the time of your life.

(Internal link to jobs)

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.

C# Editor at a conference?

jaybaz_MS — Sun, 05 Sep 2004 17:38:00 GMT

Back in da day, I used to go to VC/VS themed conferences and talk about the debugger. Even though I wasn't a very good speaker, the talks were very well received. Lots of technical content, tips for how to be more productive with the debugger.

When I moved to the C# Editor, I didn't know enough about it to share, but maybe I do now.

I'm looking for ideas about what you'd like to see in a C# Editor talk.

I could just run through some interesting features and describe their behaviors in detail. We could create some interesting expansions. We could try a small programming exercise, using the various editor tools. We could refactor the starter kit or some other code.

What would you like to see?

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();

}

A blog break

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

Earlier I talked about the challenges of shipping software. You want Whidbey, and we want to give it to you.

To make that happen, we need to fix the remaining bugs & shut this product cycle down. We want to focus our attention on this work, so we're trying to remove some of the other things we spend time on.

We've cancled meetings. Devs are handing off open design issues to their managers. Email responses will be slower.

And blogs are going to be quiet. We are going to be heads-down on getting Whidbey in to shape, and won't be spending as much time with the community for a little while.

See ya when we get back!

More on autocomplete

jaybaz_MS — Tue, 31 Aug 2004 00:55:00 GMT

Related to the questions around TAB and ENTER are some questions around the new “autocomplete on identifier”.

(I could swear I’ve blogged about this before, but I can’t seem to find it.)

In VS2002 / VS2003, if you type ‘foo.’, you get a completion list with members of ‘foo. Most people are happy about that most of the time.

What many users don’t realize is that they can bring up a completion list much more often than on dot. CTRL-SPACE is the default keybinding for Complete Word. If there’s an unambiguous match, it’ll complete it. Otherwise it’ll show the completion list. If the match is exact except for casing, then it’ll fix the casing. (That’s nice when you type Arraylist).

For Whidbey, we decided to bring the completion list up more often. We figured this would help you be more productive. Novice users aren’t sure what’s out there, and would appreciate the help. Even expert users (well, me) are known to mistype ‘namespace’ and ‘protected’. And none of us like to type more than is necessary.

We knew that putting keywords in the completion list was required. Without that, we’d keep trying to complete type & variable names whenever you type keywords. We would have liked to be really smart about only displaying the keywords that are legal at the time, but that turned out to be an extremely difficult problem. We ended up with doing a little bit of keyword filtering for Beta 1, but we may remove even that for Beta 2.

We originally experimented with showing the completion list whenever you were typing a name. So, suppose you had:

Console.Write ();

And decided to switch to calling “WriteLine”. As soon as you hit ‘L’, we’d show a completion list.

It turned out to be extremely annoying. Every time you dismissed a completion list, it would pop up a moment later. If you ever wanted to type something that wasn’t in the list, you couldn’t.

We also experimented with having BACKSPACE show a completion list. It was also very annoying, and decided to cut it in the end.

Today, we automatically show the completion list in these situations:

If we have special knowledge. Autocomplete on ‘override’, ‘new’, and situations where an enum type is expected.
On dot, showing member lists.
On the first character in a name.

The last one is the result of all this experimentation.

There are a couple places where this behavior is annoying, however. They all come down to typing names that don’t already exist. One common pattern in C# 2.0 is creating a generic method that returns a parameterized type:

T Foo<T>() { }

When you type the first character, a completion list appears, but doesn’t include ‘T’. If you hit SPACE, we complete one ‘true’ or something. Some people find this extremely annoying.

Another case is just writing a statement before you declare the variables in the statement.

I described a similar issue with autocomplete on dot, as related to Generate Method Stub. The issue existed in VS2002 / VS2003, but now it’s more annoying because there’s more value in writing calls before the implementation.

We decided that perhaps the problem was that LPAREN, DOT, and SPACE were committing from the completion list. If we made completion a deliberate action, people wouldn’t ever be annoyed by automatic completion. We experimented with having only TAB or TAB and ENTER do completion. We got overwhelming feedback from dogfooders right away that they hated this behavior. I insisted that they try to build new habits, but they insisted back.

So today we have the behavior that just about every non-alphanumeric character will commit the completion list. ENTER and TAB have special behavior. As long as you’re typing something that we know about, you love the way we work. And when you type something we don’t know about, you hate it.

We don’t know how to make the experience good for all types of users, in all situations. We’ve gotten lots of feedback from users, all of it contradictory.

Right now we’re leaning to keeping the current behavior, but adding an option to restrict the completion commit keys to just TAB and ENTER. There’s already an option to disable autocomplete-on-identifier.

I hope that you’ll like the behavior we’ve selected by default. If you don’t like it, I hope that you’ll find the optional behavior that suits you.

Edit: See this ladybug issue. Some folks really don't like this behavior, although not everyone understands what the behavior is, exactly.

TAB TAB TAB

jaybaz_MS — Tue, 31 Aug 2004 00:29:00 GMT

We're going back and forth on a rather narrow design issue in IntelliSense.

Suppose you're writing some code. (It's a stretch, I know.) You go to type an if/else:

if (expr)

{

// ...

}

else // here

{

// ...

}

Here’s what happens when you type ‘else’.

1. You hit ‘e’ and the completion list pops up. This behavior is new in Whidbey. Users don’t usually notice the change, but when the do realize it, they are usually enthusiastic about it. Suppose you’re a fast typist, so you ignore the completion list and keep going.

2. You hit ‘l’, ‘s’, and ‘e’, and they appear in your code.

3. You hit ENTER to insert a line break.

Since a completion list is up, the ENTER is a commit action. It doesn’t insert a line break. You have to hit ENTER twice if the completion list was up. (Since a statement ends with ‘;’, it doesn’t have that problem.) You get annoyed & send us feedback via ladybug.

We hear your feedback, and change the behavior. ENTER commits the completion list and inserts a line break.

Now you’re writing code to call a method on a class you don’t know well. You type:

foo. // completion list pops up

You consider the possibilities, select the one you want, and hit ENTER to commit it. You’re glad that it inserts the method name, but annoyed that it adds a line break. You have to undo/backspace to add the method parameters. You get annoyed & send us feedback via ladybug.

We hear your feedback, and change the behavior. ENTER always commits the completion list. If the contents of the completion list and what you’ve typed are identical, we also insert a newline.

Consider TAB. Similar issues exist here.

Suppose you want to use the ‘for’ expansion. Type ‘fo’ and hit TAB to complete. It completes to ‘for’. Then TAB again to expand. Cool.

Suppose instead you type ‘for’ and then TAB. The completion list is up, so you have to hit TAB once to dismiss it, and once to expand.

Based on the above discussion, we make TAB act like ENTER – it only expands an expansion if the match is exact.

I think this is the behavior we should keep. However, we have gotten a bit of feedback about it.

Consider this:

1. Open a .cs file

2. Go to the top of the file to add a ‘using’ directive.

3. Type ‘using’.

4. Notice that ‘using’ is in the completion list, so hit TAB to commit.

This inserts a “using statement” in a very bogus location.

Are we doing it right?

Refactoring the C# Express Starter Kit – Part 2: Organizing fields

jaybaz_MS — Sun, 22 Aug 2004 05:18:00 GMT

Looking in RssView, I see a big mess. There are lots of fields. Some are related to each other & different from others, which suggest an Extract Class.

Some are set at initialization time, while others change over time. Clearly there’s a difference there, but it’s not called out in the code.

All the initialize-time fields are set via public properties after the object is created, but should be set via the constructor. As it is, there’s a risk of not setting a required property, or of a property changing value later when that’s a bad idea. Also, it’s valuable to mark fields ‘readonly’ when possible. There seems to be a split between “identity” and “state” fields. I want to explore the value of putting all the initialize-time fields in a helper class, and all the state fields in another. I want to see what happens when I do that. Also, I’m thinking of Ron Jeffries suggestion that fields should all change at the same rate.

Since most of the fields are initialize-time, I’m going to start there first.

I take all the fields that look like init-time, and wrap them in a nested class:

public class Configuration_

{

// Where to draw

public Rectangle Location;

//...

}

Configuration_ configuration = new Configuration_();

public Configuration_ Configuration { get { return this.Configuration; } }

I have the underscore because otherwise there would be a conflict between the name of the property and the name of the type. I hope to eventually figure out a better way to name these things, without the underscore, but I don’t want my inability to think of a good name to stop my Refactoring fun.

Next I go to all the references to those fields and add “Configuration.”:

this.Configuration.rssChannel = rssChannel;

I run, and it immediately crashes. The ‘Configuration’ property has an infinite recursion. This is a common coding error, at least when I’m doing the coding. If I was pairing, maybe my pair would have noticed. If I had a unit test, maybe it would have caught this sooner. If I was following my naming convention of prefixing private fields with an underscore, maybe I would have caught this sooner. If the compiler would warn on this, that would be nice.

Luckily it’s easy to fix. I run again, and things seem to be working.

I see that the top of the screen has a white box across it. I can’t remember if that’s supposed to be there or not. I should go back to the original version of the sources & see what happens there, but I’m feeling lazy and/or rushed.

Oh yeah, I should make the ‘configuration’ field readonly, since I can.

The last thing I want to do before I go is to get rid of the properties & use public readonly fields. You already know that I don’t like trivial properties. I get the same syntax at 1/3 the code.

Search/replace and rectangle select are pretty useful for this, but I wish the IDE would make it easier on me.

In the process I discover an issue with the code. The max & min items to show are set in two places. They have a default initialized value, and a passed-in value. I think that Refactoring to use the readonly fields pattern has helped make this issue more visible.

I’m not sure who should own the value; for the time being, I’ll make them ‘const’ instead of ‘readonly’ and let the RssView own them.

The Configuration_ class now looks like this:

public class Configuration_

{

// Where to draw

public readonly Rectangle Location;

//...

public Configuration_(Rectangle location, RssChannel rssChannel, Color backcolor, Color bordercolor, Color forecolor, Color titlebackcolor, Color titleforecolor, Color selectedforecolor, Color selectedbackcolor)

{

this.Location = location;

//...

}

The construction of the RssView now looks like:

RssView.Configuration_ config = new RssView.Configuration_(

new Rectangle(new Point(2 * Size.Width / 20, 3 * Size.Height / 20), new Size(10 * Size.Width / 20, 12 * Size.Height / 20)),

//...

);

// Initialize the two classes that draw the RSS contents

// Use the first channel of the RSS feed

rssView = new RssView(config);

Now the RssView only has 5 fields; we’re making some kind of progress.

I’d like to refactor all those ‘Color’ values. There seem to be relationships between them. I imagine that a class that represents a foreground/background color pair would be valuable.

I’m also confused by that huge expression that selects the location of the RssView. What does it all mean? Why does it multiply by 2 & divide by 20? Is that different than dividing by 10? If I can figure out what it’s trying to do, maybe I can find a clearer way of expressing it.

In general, I think that having data (the color values) in my code is a bad idea. It makes unit testing more complicated. It makes seeing the logic in the code harder, because the data is intermingled. It makes changing the data harder, because I might accidentally change the behavior while I’m at it. I tried to push some of the data into resources, but I got stuck pretty quickly. I have to admit, managed resources are pretty confusing to me. Refactoring this stays on the TODO list, and learning about resources goes there, too.

IDisposable … or not

Commenters on the last post noted that I may not be disposing Pen and Brush objects. Turns out the situation is pretty bad.

In the BorderedRectangle, it’s easy:

using (Pen pen = new Pen(this._color, this._thickness))

{

g.DrawRectangle(pen, this._rectangle);

}

But in RssItemView it’s not. There is a Pen field that isn’t disposed. It’s also replaced by the set_LineColor and set_LineWidth, which means you could potentially leak a whole lot of handles pretty quickly.

There’s not an easy way to just toss in ‘using’ at this point and make the problem go away. I am going to leave the bug in place because I’m still working on cleaning up RssView at this point. When I turn my attention to RssItemView, I’ll probably refactor it in such a way that this bug will be trivial to fix.

One commenter also suggested renaming Location to Bounds, which I’ve done. Seems reasonable.

In a discussion with Cyrus, he gave me a hard time for creating types with an underscore suffix. He’s completely justified, but I haven’t found a solution I like better. If we come across something better, I’ll apply it.

Refactoring the C# Express Starter Kit

jaybaz_MS — Thu, 19 Aug 2004 22:17:00 GMT

Yesterday I decided to take a look at the code we shipping in the Beta 1 C# Express SKU for a screen saver. I was pretty disappointed in the quality of the code, so I decided to refactor.

I’ve talked about some ideas about coding styles here on this blog, and I wanted to explore some of those ideas in this real context.

Most of my attention has been focused on the class “RssView”. 174 lines of text, 20 private fields, 13 trivial get/set properties, and only 7 methods.

Choosing a Rectangle

Let’s pick something to attack. This pair of fields are a little smelly:

// Where to draw

private Point location;

private Size size;

This notion seems familiar to me. Hmm, I think I would call it a Rectangle. So, replace it:

Rectangle location;

And start fixing up references. When I came across this reference, I had to hold my nose:

private void DrawBackground(Graphics g)

{

g.FillRectangle(new SolidBrush(BackColor), new Rectangle(Location.X + 4, Location.Y + 4, Size.Width - 8, Size.Height - 8));

g.DrawRectangle(new Pen(BorderColor, 4), new Rectangle(Location, Size));

}

What is this about? It’s trying to draw a filled, bordered rectangle. The border is 4 pixels wide. Why does it hard code the values of ‘4’ and ‘8’? Let’s make a note of this method & refactor it later.

DrawBackground

Now it’s later.

I see that Rectangle has an ‘Inflate’ method. Pushes out all 4 sides of a rectangle in exactly the way you see here. So switch to something like:

Rectangle fillRectangle = location;

fillRectangle.Inflate (-4, -4);

g.FillRectangle (new SolidBrush(BackColor), fillRectange);

The fact that we switched from Point/Size to Rectangle is what made Inflate available to us. Depending on your point of view, either:

This is proof that Rectangle really is the right way to go, and that getting the types right in your system will always make your code clearer, cleaner, and simpler.
We just got lucky, finding exactly the method we needed.

Maybe it’s the second one, but I sure seem to get lucky a lot!

BorderedRectangle

I pondered this method more, and decided that the notion of a rectangle with a border, which could draw itself, was a basic notion that I’d like to see as its own class. So I wrote one.

class BorderedRectangle

{

public class Colors

{

public readonly Color Fill;

public readonly Color Border;

public Colors(Color fill, Color border)

{

this.Fill = fill;

this.Border = border;

}

readonly int _fillBorderThickness;

readonly Rectangle _location;

readonly Colors _colors;

public BorderedRectangle(Rectangle location, Colors colors, int fillBorderThickness)

{

this._location = location;

this._colors = colors;

this._fillBorderThickness = fillBorderThickness;

}

public void Draw(Graphics g)

{

DrawInnerFill(g);

DrawBorder(g);

}

void DrawBorder(Graphics g)

{

Pen pen = new Pen(this._colors.Border, this._fillBorderThickness);

g.DrawRectangle(pen, this._location);

}

void DrawInnerFill(Graphics g)

{

Brush brush = new SolidBrush(this._colors.Fill);

Rectangle innerRectangle = this._location;

innerRectangle.Inflate(-this._fillBorderThickness, -this._fillBorderThickness);

g.FillRectangle(brush, innerRectangle);

}

There’s now a lot more lines of text to represent this simple notion. However, each line is much simpler; most of them are trivial. If there are bugs in this code, they should be easy to work out.

My first implementation had a “Color fillColor” and “Color borderColor”. I decided that these are related, so I grouped them into a new type. I think that nested types are critical to this kind of Refactoring. First, I avoid cluttering the namespace with a bunch of new tiny classes. Second, it’s clear what the relationship is between BorderedRectangle and BorderedRectangle.Classes. Finally, I can give simple names to my simple classes.

There’s a pattern here that I find myself writing a lot. A class with a series of ‘readonly’ fields, and a single public constructor that takes a parameter for each & assigns it to the field. BorderedRectangle.Colors is an example of this pattern. For lack of a better name, I’ll call it an “Entity Class”. I write it so much that I wish for a feature in the editor to help me do it. I suspect it’s a code smell, but I don’t yet see a Refactoring. Let’s keep it in mind.

I think I’m done for now, but I notice have 2 private methods, which is apparently a code smell. How would I refactor that? I think I would create a class called “Border” and a class called “Fill” and give them “Draw” methods. Maybe I’ll do that next time.

There’s still a lot of code smells in the start kit. Hopefully the pace will pick up soon.

Also, I’m working without a pair & without unit tests. I’m a little worried about that. This code wasn’t built TDD, so retrofitting tests is hard. Maybe I’ll be OK, because just running the app lets you verify it quickly. Let’s see if I get in to trouble later.

Making “Promote Local” make sense.

jaybaz_MS — Fri, 30 Jul 2004 02:50:00 GMT

We’re sitting around watching a video from a usability study.

A subject has been exploring the Refactoring menu, and has just tried Promote Local. With the help of the very specific error messages I wrote (yay exceptions), he finally gets it work.

On the audio track you hear him thinking out loud, describing what just happened – how the code was just transformed. Then he goes quiet. 4 full seconds of complete silence.

“Oh, WOW”.

“That… Now I understand the value in that; that’s a HUGE time saver”

And goes on to talk about how it’s a great productivity boost.

The video was sent under the heading “A feel-good video clip for you”, with the comment “This is what we would like to see as the standard user experience for new releases”.

Sure, it sounds good to hear someone say they like one of our features so much. But it also makes re-enforces my concern that Promote Local isn’t discoverable. Most people will look at the menu item, wonder for a moment what it means to “promote” a local, and then move on. The name doesn’t seem to resonate with most users.

The problem seems to be made worse by the fact that Promote Local has no option for Preview Changes. That’s mainly because there’s no UI that could offer that option; the feature is very streamlined. If you’re feeling inquisitive enough to try to run the Refactoring, you won’t get the expressive feedback from Preview about how it changes your code.

We’ve been brainstorming a bit about how to rectify the situation.

Perhaps we should rename the feature (and menu item).

The feature is meant to fill the Add Parameter space, so maybe we should call it that. Of course, you’d be pretty surprised to have Add Parameter fail because the cursor isn’t on an initialized local variable.

We could do “Add Parameter from Local Variable” or “Add Local Variable as Parameter” or something. Those names seem a bit clumsy, but maybe they’ll do the trick. If you’ve read Fowler, you’ll probably expect to find an Add Parameter Refactoring.

One thing we probably should have done is made the menu items dynamic, inserting symbol names in them. So “Rename…” becomes “Rename Foo…”. Thinking along those lines, we could do “Promote Local Variable ‘foo’ to Parameter” “Promote Local Variable ‘foo’ to Parameter of ‘F()’” or “Make Local Variable ‘foo’ a Parameter of ‘F()’”.

One option suggested by a reader is to link to my sig change blog from a tool tip. <wink>

I’m going to see if I can help the documentation folks get really good docs for Promote Local into the product. At least that way, if you do go looking at help you’ll figure it out. But I don’t expect most people will do that.

I need your help. How can I make it clear what Promote Local is? What would you like to see in the product?