• NULLPTR (unregistered)

    #define TRUE FALSE #define true false #define 0 1

  • giammin (unregistered)

    the real WTF is using Convert.ToInt method to convert the value because it return 0 when the parameter is null LMAO

  • Dude (unregistered)

    Am I the only one annoyed by the pattern

    if (data.Substring(startIndex, length).Trim() == "" || string.IsNullOrEmpty(data.Substring(startIndex, length).Trim()))

    ?

    IsNullOrWhitespace is an amazing function as well. Not that the check is needed when you are using TryParse, but I shudder to think that pattern is being used elsewhere in the code.

  • Brian (unregistered)
    Remy:
    int result; if (int.TryParse(data, out result)) { rowData[column] = result; } else { rowData[column] = DBNull.Value; }

    There are certainly better, cleaner ways to handle this.

    Indeed. In newer versions of C# (7, I think?), you can condense it into one line: rowData[column] = int.TryParse(data, out var result) ? result : DBNull.Value;

  • Scott (unregistered)

    Maybe we should null-check data before trying to trim or substring it? Also validating the long value with int.TryParse is potentially problematic.

    Anyway, reminds me a bit of this SMS parsing method we have: take in a string, and try to parse it into its three components.

    Naturally, the people who wrote it initially had the parse method return a bool, with "out" variables for the components. Needless to say, I refactored that into returning an object representing the parsed message and throwing exceptions in the cases the input didn't parse.

    Just one of the many frustrations I deal with on a daily basis.

  • Duran (unregistered)

    Reminds me a lot of the code base at my current job... the entire code base aside from the parts I'm slowly refactoring as I'm allowed.

  • Hans (unregistered)

    Getting the same substring multiple times (I counted 4 for a correct value), ignoring the TryParsed value when it was successful and Parsing it all over again.... The original "programmer" has some learning to do.

  • I can be a robot if you want me to be (unregistered)

    My WTF in the suggested code is having to use "if" before "try" - the latter implies the former.

  • negative infinity (unregistered) in reply to NULLPTR 
    while(TRUE)
{
    *((bool*)false) = true;
}

    And the #define 0 1 does not work.

  • (nodebb)

    @Remy, can you compare strings like that in .net (aka are strings objects in .net or some sort of primitive vartype)? I mean, with the == operator? I have a Java background, so anything string related goes through an .equals() call if you don't want a RWTF.

    Addendum 2019-07-24 12:41: [compare strings -> compare strings safely], of course...

  • (nodebb) in reply to JiP

    In C# (.Net) using == is the preferred way of comparing strings. .Equals() uses strings as an object ref where == makes sure to use the string cache. Technically, they should both process identically, and I believe they do in more recent builds.

    Each .Net language may compile a bit differently, though. VB.Net is a bit different. Using .Equals does the same as C#, but using the VB equality operator (=) does a VB string comparison which, depending on your options, may be a case insensitive comparison. That is just part of the VB language as it traditionally was always case insensitive.

  • (nodebb) in reply to JiP

    C#, unlike Java, has operator overloading. In this case, String overloads the == operator to just call the static Equals(String, String) method.

  • Harris M (unregistered)

    You don't need to trawl commit logs when you have Git Blame, it's my favourite Git tool.

  • Not a thing that happens (unregistered)

    The pattern these days is:

    if (int.TryParse(data, out var result)) {
                                              ^
  rowData[column] = result;
} else {
  rowData[column] = DBNull.Value;
}
  • Programmer Robot 10C-32 (unregistered)

    Nice, but I am disappointed by the lack of regular expressions.

  • Russell F. (unregistered)

    Original submitter here. This code is required to be compatible with version 2.0 of the .NET framework, which didn't have IsNullOrWhitespace().

  • Ulysses (unregistered)

    TRWTF is the nonsensical syntax coloring in the article. Did Remy write the markup engine?

  • Barf4Eva (unregistered)

    This article must be leaving out some details... I understand why this is supposed to be a WTF (and perhaps the obvious ones on the int.TryParse on long), but these two code pieces are not at all semantically equivalent in what is being attempted. The "normal one" is simply just doing parse on the entirety of a data string, where the data string is itself probably representative of a single value. However, the second example looks more like a parser for a record of data, and someone, instead of separating the concern of parsing "fields" from the validation/translation of them, slapped it all together.

    Am I missing something stupid here?

Leave a comment on “A Long Conversion”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article