For-Switch Strikes Again



  • Just found this in a piece of code for parsing some CSV data files:

    StringTokenizer st = new StringTokenizer(line, ";", true);
    String tok;
    for (i = 0; i < 6; i++) {
        if (st.hasMoreTokens()) {
            tok = st.nextToken();
            if (!tok.equalsIgnoreCase(";")) {
                switch (i) {
                    case 0:
                        value1 = tok;
                        break;
                    case 1:
                        value2 = tok;
                        break;
                    case 2:
                        value3 = tok;
                        break;
                    case 3:
                        value4 = tok;
                        break;
                    case 4:
                        value5 = tok;
                        break;
                    case 5:
                        value6 = tok;
                        break;
                    default:
                }
                if (st.hasMoreTokens()) {
                    tok = st.nextToken();
                }
            }
        }
    }
    

    Now, for-switch isn't exactly something new, so normally I wouldn't have bothered posting, but the double-whammy with using a StringTokenizer to accomplish what a simple line.split(";") would have done was what made me go "WTF?!" out loud.



  • I especially like the check for the case insensitive semicolon...



  • Something I didn't spot myself until now: calling the constructor of StringTokenizer with the third parameter explicitly set to true (which makes the it return the delimiters themselves as tokens, which it by default does not do, for example if you simply use the constructor without that argument) and then having to add extra code just to filter them back out again...



  •  I guess in this case it doubles for an "is string empty" check?



  • @Anonymouse said:

    Just found this in a piece of code for parsing some CSV data files:

    I thought for one glorious moment that this was going to be someone somehow using Duff's Device to parse CSV. Disappointed.



  • @Hatshepsut said:

    ...Duff's Device...

    Careful, Hatshepsut, you're showing your age.


  • Considered Harmful

    @suid said:

    @Hatshepsut said:
    ...Duff's Device...

    Careful, Hatshepsut, you're showing your age.


    3,521 years?



  • @Anonymouse said:

    Something I didn't spot myself until now: calling the constructor of StringTokenizer with the third parameter explicitly set to true (which makes the it return the delimiters themselves as tokens, which it by default does not do, for example if you simply use the constructor without that argument) and then having to add extra code just to filter them back out again...
    Not to mention that calling st.nextToken() twice each time through the loop also removes the delimiters, assuming every other token is a delimiter.

     



  • @HardwareGeek said:

    Not to mention that calling st.nextToken() twice each time through the loop also removes the delimiters
    That's what I meant with "extra code", which the original author only had to add because he added that unnecessary "true" argument in the first place.

     



  • @HardwareGeek said:

    Not to mention that calling st.nextToken() twice each time through the loop also removes the delimiters, assuming every other token is a delimiter.

    ...and it's totally unnecessary, given that the token is ignored if it's the delimiter. Except it's not unnecessary, because the outer loop is just a counter to 5 and not a while loop on st.hasMoreTokens().

    The number of nested WTFs in this code is impressive.


Log in to reply