• anonymous (unregistered)

    The only solution that makes sense is of course to generate these variables at runtime and simply put token placeholders in the actual code. This problem can easily be solved with a 2nd, 3rd, 4th layer of abstraction :)

  • ivan (unregistered)

    You should realize that people do do that kind of programming because they are afraid the symbols may change.
    If the while loop executes 100 times then a code like:
    sb.Append("<")
    in the loop will result in 100 string object ("<") allocations and consequent garbage collection. And if you call the method 10 times you have 1000 objects created and thrown away in a place where 1 would be just enough.

  • ivan (unregistered)

    I meant to type: "...people do NOT do that kind..."

  • TJ (unregistered)

    I must say that I have never seen the sb.append().append().append() before. Interesting.

    Guess this guy has never heard of AppendFormat.

  • ivan (unregistered)

    Java didn't have it either, but they added it in J1.4, "borrowing" the idea from .net :-)

  • Jim Bolla (unregistered)

    TJ--

    He could use AppendFormat but then he'd have "{0}{1}{2}" in his code and what if .NET stopped using braces or changed their index to be 1-based instead of 0-based. He'd have to write another function just to build that. :/

  • tim (unregistered)

    You know, ivan has a valid point. I don't know enough about Java, but if it would save me object creation in C++, I'd do it.. :P

  • Omer van Kloeten (unregistered)

    These constants actually already exist in the .NET Framework.
    Imagine that. :)

  • Mike Dimmick (unregistered)

    I suspect that Ivan's right about the reasoning, but that the developer doesn't know about string interning (http://www.c-sharpcenter.com/InsideDotNet/StringInterning.asp) nor that const objects are compiled right into your code.

    The worst part is that he appears to be constructing XML, for which you should use an XmlTextWriter. That corrects the bug where you've tried to close off the Items tag with a backslash -> \ rather than the correct slash -> / sigh.

  • Garbage Collector (unregistered)

    String literals are only created once in memory and are reused every time they are referenced, so a loop with .Append("<") would not create multiple "<"'s. Check the docs on string.Intern(). Try it yourself, (object)"asdf"==(object)"asdf" is always true.

  • Mike Dimmick (unregistered)

    Not to mention escaping any characters invalid in an attribute name or value.

  • tony (unregistered)

    Luckily for use he has shown us a new era in writing XML. With out having to use those cluttery .NET XML objects.

  • foxyshadis (unregistered)

    Yes, the world certainly needs more broken XML serializers. Hey, at least we know he knows the names of his symbols!

    What's with the Append... nothing?

  • Matt Berther (unregistered)

    Apparently the concept of an XmlWriter is way beyond this guy...

  • Paul Kuliniewicz (unregistered)

    I'm curious why the author of that code doesn't think that the literal " " should be abstracted away like all the other strings....

  • Sergio Pereira (unregistered)

    Mike,
    The backslash bug was introduced by myself when I was editting the code to make it un-reconizeable by the author.
    Your point about string interning is valid but I can assure you this guy would not have heard about this. He probably heard someone say that if you have a literal value that appears a lot in your code then you should make it a constant.

  • JonR (unregistered)

    OMFG, i actually did pretty much exactly the same thing this week. i'm writing a simple object persistance framework, and i needed to produce some abstract object querying classes which can be rendered as T-SQL, Access-SQL, XPath etc...

    so i've got things like QueryTokens.LessThanOrEqualTo
    QueryTokens.Or


    am i, therefore, an idiot?

  • Matthew W. Jackson (unregistered)

    Since there shouldn't be magic numbers, or in this case, magic strings, perhaps the framework itself should provide all of these for you. For example, when calculating the circumference of a circle based on the radius, early programmers may have written:

    c = 6.2831853 * r;

    This was because some early compilers wouldn't pre-multiply 2 and pi. Some programmers would define a constant called TwoPi, which was a good compromise.

    However, since compilers today are smart, and variables should be named with full descriptions of their value, most people would write this as:

    circumference = 2.0 * Math.PI * radius;

    However, isn't 2.0 still a magic number? What does 2.0 mean? The author means 2.0 as in "Two" but how do WE KNOW that? I propose that the primitive types should have static constants for every number added so that we never have any numeric literals, and char should have every unicode character as a static constant.

    My above example would become:

    circumference = Double.Two * Math.PI * radius;

    I'm still not happy with the "*" though. That's sort of a "magic symbol" isn't it? I mean, don't some people use an "x" or a dot to symbolize multiplication. Therefore all operators should have named static methods just like Decimal (or any CLS-compliant class with operators).

    We're left with:

    circumference = Double.Multiply(Double.Multiply(Double.Two, Math.PI), radius);

    But now the compiler can't multiply Two and PI at compile time.

    My head hurts.

  • Alex Papadimoulis (unregistered)

    Perhaps the Double.Multiply should be overloaded to accept a ParamArray ... so you could do:
    Double.Multiply(Double.Two,Math.Pi,radius) ?

  • Matthew W. Jackson (unregistered)

    I'm actually still not happy with the class name of "Double". I mean, it's not actually double-precison, it just takes double-the-bits.

    Maybe it should be renamed to IEEEFloatingPointNumberThatTakesSixtyFourBitsOfStorageAndUsesAtLeastThatManyBitsInItsCalculationsOfWhichOneBitIsForTheSignAndElevenBitsAreForTheExponentAndFiftyTwoBitsAreForTheMantissa

    Notice that I've followed in the footsteps of the CLSCompliantAttribute in my capitalization. I figure if CLS is important enough to be capitalized and ignore the casing guidelines, then IEEE should be, too (Math class be damned).

  • (cs) in reply to Matthew W. Jackson
    Matthew W. Jackson:
    We're left with:

    circumference = Double.Multiply(Double.Multiply(Double.Two, Math.PI), radius);

    Gaahh you're turning it into Cobol! Stop now before it is too late!!

Leave a comment on “Some more Future-proofing”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article