I don't know why I didn't see this earlier, but then again I had a tough summer. Here is Boris talking about the C++ IDE and a lot of the tips that were in my Tech Ed IDE talk ... the one with no slides. If you weren't at my talk then I guarantee you will learn something about VC++ from this video, and even if you were, you still might.

Update: I really should have included this link to Boris' blog. Maybe he will update it more often if he gets more traffic.

Kate

No, I'm not talking about where the brace brackets go! Coding guidelines are so much more than style guidelines. One of the things that sets me apart from many other developers I know, and especially the authors of code I am asked to fix, is a drive for simplicity. For me, that comes down to three things:

• Start by solving the problem you're actually facing, not some enormous superset of it
• Write the straight ahead way first, then adjust for the exceptions and strange corner cases
• When it's all working, and every time you touch it from then on, look it over to see if you can make it simpler.

That last one is the one so many people seem to skip. Then later when I come along and read the code, I see how it could be simpler, but I hesitate to change it. They must have done it this complicated way for a reason, I think to myself. It can take quite a long time to prove to myself that no, they just settled for 'working' and ran away as fast as they could, leaving this mess for someone else to sort out later.

A mentoring client gave me a pointer to an article ostensibly on Coding Guidelines which is as much philosophical as anything else. I like it. The rules are:

1. Make your code look like other people's code.
2. Use the simplest design possible.
3. Don't re-invent the wheel.
4. Document your code.
5. Keep security in mind.
6. Work in increments.
7. Work in iterations.
8. Have your code reviewed.
9. Don't stay blocked.
10. Do unto others as you would have them do unto you.

There are no false notes in this list and I endorse this set of philosphies whole-heartedly.

Kate

The other day I spotted this:

It's two people around a bowl of salsa, holding a nacho chip as big as each of their heads (which is why it takes both of them to hold it, I guess.) But I had never noticed it before:

That reminded me of something else I never saw even after looking at the logo a million times:

That obvious arrow is lurking here:

So subtle, till someone shows it to you. Then so obvious. So it is with bugs, eh?

Kate

How many Visual Studio Developers know about autoexp.dat? My guess is not many. This file, located in C:\Program Files\Microsoft Visual Studio 8\Common7\Packages\Debugger for a typical install, controls how the debugger shows values in the Data Tips, locals window, auto window, etc. The file is yours, it's on your own computer, and you're free to edit it. Here's how to do so for a really simple (and redundant) type, Point:

class Point
{
private:
 int x, y;
public:
 Point (int xx, int yy)
 {x=xx; y=yy;}
 int getx()
 {return x;}
 int gety()
 {return y;}
};

I ran a really simple app that constructed a point, and paused in the debugger for a data tip:

Then I edited autoexp.dat, adding this line:

I saved it and ran the debugger again, and now the tip looks like this:

You can do this for any class you write. It's your program, you might as well make your debugging life easier.

Oh, if you're wondering why my data tips are actually readable instead of in some tiny 3 point font, I blogged that earlier this summer.

I find it really surprising how much I am enjoying owning this kettle:

It is just what it appears to be, a glass electric kettle. When the water is at a full boil it is actually more dramatic than this picture shows. Like all modern electric kettles, you lift it off its base, leaving the cord and such behind, to pour. It's faster than the stove, won't boil dry, and it's fun to watch. Who knew?

I got mine at Canadian Tire. It wasn't even the most expensive kettle there.

Kate

Some people don't like the different kinds of punctuation in C++. I do. I like having :: and . and -> instead of always dots. And in C++/CLI I really like having ^ instead of overloading * to mean either pointer-to-native-heap or pointer-to-managed-heap. But you know what some people say about C++, don't you? That it looks like comic book characters swearing? Well here's what I say to that:

Kate

Julie blogged this  a while back, and mentioned to me recently that the firm needs someone again. If you know C++ and MFC, know what the .NET Framework can do, and can write English sentences as well as code, then you can live in a lovely place and do some cool work. Check into it (follow the link from Julie's blog) and mention me as well as her when you apply.

Kate

Recently, Jim Allchin (Co-President, Platforms & Services, Microsoft Corporation) posted an open letter to developers. In it he points out that it's one thing to beta test a new operating system (as I and thousands of my closest friends have been doing with Vista) and it's another thing to adapt your applications for a new operating system. For me, there are two important parts to that:

• What do I have to do to my application to keep it from failing in the new environment?
• What can I do now to my application so that it will take full advantage of the new environment?

Some Vista-specific examples of this might be "how can I be sure my application will not trigger a bunch of UAC dialogs?" and "will my app have glass?" or "can I get those cool Task Based Dialogs with the blue arrows and stuff?" These are the sorts of things I'll be tackling in some of my upcoming talks. I hope my Vista category will also be useful. My point is, don't wait until Vista ships, then wait to see if any of your clients or customers feel like using it, and then wonder if you have a Vista-ready app. Find out now.

Or as Jim says, "... the opportunity will be tremendous. If you want to ride the wave we're creating with Windows Vista, the best way is to have your application ready by the time we ship! And that is very soon. "

Kate