Another representative line



  • if(!fileArray[x].charAt[0] == '.')) {
      // first char is not a '.'
      .
      .
      .


  • if ((!fileArray[x].charAt[0] != '.') != true)

    FTFY



  • You have either added an extraneous ')' parentheses or left off a '(' that is actually there



  • @OzPeter said:

    You have either added an extraneous ')' parentheses or left off a '(' that is actually there

    ... or he is relying on the parenthese-autocomplete feature that leaked from Node.JS



  • @OzPeter said:

    You have either added an extraneous ')' parentheses or left off a '(' that is actually there

    The latter, sorry ...



  • @Ronald said:

    @OzPeter said:
    You have either added an extraneous ')' parentheses or left off a '(' that is actually there

    ... or he is relying on the parenthese-autocomplete feature that leaked from Node.JS

    That "feature" that works in a single situation which makes logical sense as it wraps things in parens because that will cause something to evaluate, a thing that happens in most languages when you wrap an expression in parens.



  • @zelmak said:

    @OzPeter said:
    You have either added an extraneous ')' parentheses or left off a '(' that is actually there

    The latter, sorry ...

    So that makes the code:

    if(!(fileArray[x].charAt[0] == '.'))
    

    I fail to see the WTF here.


  • Discourse touched me in a no-no place

    @dtech said:

    @zelmak said:
    @OzPeter said:
    You have either added an extraneous ')' parentheses or left off a '(' that is actually there

    The latter, sorry ...

    So that makes the code:

    if(!(fileArray[x].charAt[0] == '.'))
    

    I fail to see the WTF here.

    Presuming that's where the second left parens actually is, and it's not to the left of the ! where it's just plain wrong

    But in most languages, the idiomatic way of representing that sort of comparison is by using != (or whatever equivalent the language supplies), not negating the result of ==.

  • Discourse touched me in a no-no place

    So… what makes you claim that this is a WTF? (What language is it?)


  • Discourse touched me in a no-no place

    @dkf said:

    What language is it?
    charAt looks like Javascript.



  •  @PJH said:

    @dkf said:
    What language is it?
    charAt looks like Javascript.
    but JS' charAt doesn't use square brackets


  • Discourse touched me in a no-no place

    @ratchet freak said:

     @PJH said:

    @dkf said:
    What language is it?
    charAt looks like Javascript.
    but JS' charAt doesn't use square brackets

    Ah. Indeed...



  • @zelmak said:

    if(!(fileArray[x].charAt[0] == '.'))

    This would make (partial) sense in Cool, where there is no != operator. However, every if expression needs an else, so this would probably be written

    if (fileArray.get(x) match { case s : String => s.charAt(0) == '.' }) ()
    else {
      // first char is not a '.'
      .
      .
      .
    


  • @dtech said:

    I fail to see the WTF here.

    I thought this was a joke, but further evidence suggests that people really do think doing path tests on the character level is okay.



  • @PJH said:

    @ratchet freak said:

     @PJH said:

    @dkf said:
    What language is it?
    charAt looks like Javascript.
    but JS' charAt doesn't use square brackets

    Ah. Indeed...

    Fscking hell ... I really buggered that whole thing up ...

    if (!(fileArray[x].charAt(0) == '.')) {
      .
      .
      .
    

    Its Java. The fileArray is retrieved via the listFiles method of a File object, using a FilenameFilter that solely looks for file names ending with ".dat". So the ACTUAL solution to the problem is to use the proper FilenameFilter which only returns the appropriate files.

    1. Handling UNIX-based hidden files in a program which is supposed to be portable.
    2. The extra parentheses
    3. "notting" the boolean result instead of putting the "not" in the comparison itself.

    It does the right thing, its just overly verbose ... and if you're not careful, you don't see the "!" due to the way its laid out and the comment doesn't match the comparison. I stared at it for 5 minutes not seeing the "!" and couldn't figure out why the logic of the program was the way it was.



  • ugh ... so much "odd" boolean logic used:

    if (origFile == null || !test.equals(origFile) {
      .
      .
      .
    

    There's no else branch.



  • @zelmak said:

    ugh ... so much "odd" boolean logic used:

    if (origFile == null || !test.equals(origFile) {
      .
      .
      .
    

    There's no else branch.

    Well, that should never fail, why write an else for a condition that won't fail?

    Then again, why test a condition that you think is guaranteed to be true?

    My brain hurts now. The lack of logic using logic is frustrating.



  • @tweek said:

    @zelmak said:
    ugh ... so much "odd" boolean logic used:

    if (origFile == null || !test.equals(origFile) {
      .
      .
      .
    

    There's no else branch.

    Well, that should never fail, why write an else for a condition that won't fail?

    Then again, why test a condition that you think is guaranteed to be true?

    My brain hurts now. The lack of logic using logic is frustrating.

    What's wrong with this one? Presumably test.equals can't handle getting a null as a parameter. That is kinda weird, because you'd expect it to be (origFile == null || !origFile.equals(test)) which would make the null-check meaningful.

    At any rate there's no reason that condition is guaranteed to be true, is there? The body of the if is run either when origFile is null or when it's not the same as test.



  • try {
        int dummy = 1 / Character.compare(fileArray[x].charAt[0], '.');
        // file name doesn't start with .
    } catch (ArithmeticException ex) {
        // file name starts with .
    }
    

  • Discourse touched me in a no-no place

    @Anonymouse said:

    try {
    int dummy = 1 / Character.compare(fileArray[x].charAt[0], '.');
    // file name doesn't start with .
    } catch (ArithmeticException ex) {
    // file name starts with .
    }
    Maybe I be needing this later.

    (Only counts as a WTF if it was put in production code by someone who ought to have known better. Or if the person who put it in production didn't know better, though that'd be a different sort of WTF…)



  • I would have written it as:

    try {
        int dummy = 1 / fileArray[x].indexOf(".");
        // file name doesn't start with .
    } catch (ArithmeticException ex) {
        // file name starts with .
    }

Log in to reply