The New String recommendations

Sorting it all Out
Michael Kaplan's random stuff of dubious value
Be sure to read the disclaimer here first!

The New String recommendations

  • Comments 11

Dave Fetterman reported yesterday on the Official Guidance: New Recommendations for Strings in .NET 2.0 (full paper here).

Now this is a paper whose recommendations I think are incredibly important (some of them were I daresay inspired by things I have been saying here about invariant versus ordinal and using uppercasing!). And I think at the core of those recommendations is a principle that applies to all code that is written, managed and unmanaged, in any version of any product. So I don't want people to think "I'm not using Whidbey, so this does not apply to me."

That core principle? Stated simply....

Use appropriate comparison methods.

It simply makes no sense to use the wrong method, ever.

Now as I have mentioned before, I am a bigger fan of what I call the 'vertical method' (different flag values in a single method or function) as opposed to the 'horizontal method' (different methods or functions). I find it easier to explain, easier to document, and easier for a user to know what to call. I explain this in part for unmanaged code in my post Similar descriptions does not mean similar methodologies and some day soon I will follow up with a managed version of that post.

But it is important no matter whether you are a 'vertical' person or a 'horizontal' one to choose appropriate methods to compare based on your actual scenario.

 

This post brought to you by "๚" (U+0e5a, a.k.a. THAI CHARACTER ANGKHANKHU)

Comment on the blather
Leave a Comment
  • Please add 4 and 5 and type the answer here:
  • Post
Blog - Comment List
  • "Case-insensitive identifiers in standards like XML and HTTP"

    Whoa! HTTP is case-insensitive, but XML is case-sensitive. So is XHTML.
  • Well, yes and no -- a lot of the things that use XML are themselves case insensitive, or give the option to be. And even then there are the normalization issues -- which can still point to more appropriate sdtring comparison methods. :-)
  • I love it! I wish someone would go ahead and write this exact article for using non-.NET APIs as well.
  • There is a brief mention towards the end of the paper:

    ----------------------------
    Notes for Native Code

    Native code is susceptible to similar types of errors, but they occur much less commonly. Default behaviors of string operations are not based on the locale, but are typically ordinal-based (strcmp or wcscmp, for example). Our recommendations for using managed code mirror this behavior. Finally, where linguistic flexibility is desirable, culture parameters can typically be passed in (see CompareString).
    ----------------------------

    Beyond that, I have posted on the issue here from time to time and there is work to improve the documentation on the Windows side in future versions of the Platform SDK.
  • I have had some people who even after reading my Stump the Chump post and at my schedule for being in...
  • Scott figured it out, and it was not a Microsoft bug.:-)
    You can read about the details on Scott's blog...
  • I have of course had many a dinner with geeks before, but this is the first one I had that was set up...
  • It was a little over a month ago that I pointed out that Similar descriptions does not mean similar methodologies,...
  • Since these immortal words were spoken by the voice of Tim Blaney to Ally Sheedy, I think every...

  • I have spoken of the importance of using .NET 2.0's OrdinalIgnoreCase and Vista's CompareStringOrdinal...

  • Back when I wrote Invariant vs. Ordinal, the third, two of the interesting points I made were that,...
Page 1 of 1 (11 items)