Making Wrong Code Produce Compiler Errors

Gregg writes about his response to a recent Joel article.

I had the precise same response, based on some conversations I had with Jay a while back. To sum it up, the utility of creating a small class to encapsulate a specific "kind" of thing (as Joel describes it) is vastly underestimated.

In my current code, I have a need to deal with time durations (and remember that I'm in C++...), so I wrote a little class named CDuration, and then pass durations around. It's really convenient.

Comments (7)

  1. Travis Owens says:

    Is it just me or does you topic have nothing ot do with your post?

    If you literally want to make incorrect code produce compile errors than you want to write unit tests.

    I’m too lazy to read into your previous convos so let’s leave it at that 🙂

  2. Dutch Meyer says:

    No, you’re clearly posting on topic, and you’re clearly correct. It’s a C/C++/C# truism that it’s better to produce errors during compile time. Unit tests only catch the errors you’re smart enough not to make in the first place, they don’t actually improve the quality of the code.

  3. RichB says:

    I wrote a blog entry to refute Joel’s claims and actually created a specialized class to do what Joel needed:



  4. Thomas Eyde| says:

    You all seem to forget that Joel has a spesific need: To convert code from Classic ASP/VBScript to PHP.

    As you all know, you can’t use the type system in VBScript to do what you are suggesting.

    But still, if we use the type system in C#, we have to remember to use the right thing at the right time. The SafeString class mentioned doesn’t ensure that. How do you this code is correct or not by just looking at it?

    SafeString safe = new SafeString(message, false);

    What does false means? I can’t see it at a clance, I have to look up the constructor.

    What about message? Is it encoded or not? I have to track its origin or fire up the debugger to find out.

    We need descriptive and informative names. The type system alone doesn’t save us. So Joel has a point. In fact, if we want to write safe code in VBScript, we probably don’t have any other options.

  5. TheMuuj says:

    You could do it in VBScript with Classes and Default properties, but I’m sure it would not be worth the overhead.

    I used to use variables with an "HTML" suffix if they contained HTML or were already HTML encoded. I do this in the database, as well.

    Dim Title: Title = RS("Title").Value

    Dim BodyHTML: BodyHTML = RS("BodyHTML").Value

    Dim TitleHTML: TitleHTML = Server.HTMLEncode(Title)

    Response.Write "<h1>"

    Response.Write TitleHTML

    Response.Write "</h1>"

    Response.Write BodyHTML

    If you ever Response.Write something that doesn’t end in HTML, you should think twice. (Even URLs with querystrings containing "&"–that’s where a lot of code is wrong).

  6. Thomas Eyde says:

    TheMuuj: "If you ever Response.Write something that doesn’t end in HTML, you should think twice."

    That’s Joel’s point excactly, isn’t it?

  7. TheMuuj says:

    Yeah, but I would still prefer a compiler-safe way of doing it, and while this is possible in VBScript, I wouldn’t recommend it.

    And I agree with Joel, but I don’t think we need to resort to Hungarian notation. "Title" and "TitleHTML" are perfectly good variable names that describe what they are. What’s a safe string? Is it safe for SQL? Is it safe for HTML? When sending titles into a database (assuming you aren’t using parameters–perhaps you need a parameter array for an IN clause), TitleSQL makes sense.

    I think SQL, HTML, and XML make better suffixes than single-letter prefixes.

Skip to main content