The great naming debates --- still..

Some guidelines in the Design
Guidelines Document and described in my blog are based on years of
experience with managed code and a deep understanding of how developers think
about problems and how the runtime really works… And other guidelines…well, to
be frank, we flipped a coin. For
some of the guidelines (mostly casing related) we really could have gone either
way. What is important about them
is that we use them consistently in the framework. There is inherent value in
conforming. Developers can predict
how Html or IO will be cased in an API… If you are a long-time managed code
developer I would bet it would look odd to you to see “HTML” or
“Io”./>

And then there are the exceptions to
the rule. Nearly every team writing new parts of WinFX has some place they want
to violate these guidelines. They
have some special reason to want to case their identifiers differently than the
rest of the framework. Things such
as consistency with an older platform (MFC, HTML, etc), avoiding geo-political
issues (casing of some country names), honoring the dead (abbreviations folks
names that came up with some crypto algorithm), the list goes on and on.

I am honestly torn in these
cases. On one had there is only
value in these kind guidelines is everyone one follows them. So, we should just force folks to conform
even if it feels a little odd in a particular case. On the other hand, I strongly believe
that that the teams building WinFX know their domain best, for most guidelines
they do a great job of making intelligent trade-offs and producing great
APIs. So should we just leave it up
to the teams to make a call and risk a fairly fragmented world or should push
hard on consistency in these places.

I am really interested in your
opinion of these abstract issues, but I also have a couple of (slightly more
complex) concrete examples for you to weigh in on.

ARGB or “From Argument
B”

We have the class below in the
framework today. It successfully
follows the guidelines for casing and uses “Argb” rather than “ARGB”. But we have actually gotten bug reports
along the lines “How do you convert a color from an ARGB value, all I see is
methods to convert “from argument b”.

So did we make the right call here?
Should we continue to use Argb in
future apis (in Avalon for example) or should we use ARGB?

public struct
System.Drawing.Color
{

...

public static Color FromArgb(int alpha, Color baseColor);

public static Color FromArgb(int alpha, int red,
int green, int
blue);
public static
Color FromArgb(int
argb);
public static
Color FromArgb(int red, int green, int
blue);
...

}

ID and Id

This is a hard one for me because we
have already messed up the framework… Today the guideline says to use “Id” as an
abbreviation for Identifier and about 75% of the framework follows that
guideline. The notable exception is
ASP.NET which controls have a commonly used ID tag. We closed on the guideline too late to
change ASP.NET, but we are now in the middle of building WinFX, should new APIs
use ID or Id? For example, Avalon
has the same basic need as ASP.NET and therefore is using “ID” now… Is that
something that is worth fixing? Maybe we need guidelines on when to use “Id” and
when to use “ID”?

Love to hear your
comments!