Senior developer



  • Helping* another senior** developer with a task that he's been working on way too long.  The task is to read one text file that contains a list of other filenames, and then verify the existence of those files. His solution was to iterate over each line of the file, identify the target filename, and then iterate over the directory to find the matching filename. facepalm

    But no, the fun doesn't stop there.  His method of extracting the filename was to (VB) Split the line and access the Xth array element. Nothing abnormal about that, but X was 212, and this file could not be that big. Then I saw that the file is fixed-width and that he was Splitting on a space, and he had empirically determined that the filename he was looking for was at that position.

    Before the evil instinct took hold to ignore it and let his code fail miserably, I mentioned that it would fail if the next line had, say, only 211 spaces before the filename. I wish I hadn't.

    _____

    * "Helping" as in nudging him in the right direction, then waiting to see if he can make progress, and then re-nudging when he fails.

    ** I believe "senior" is in his title; it reflects how long he's been with the company and nothing more.



  • The mind boggles, but I'm guessing something like this resulted?

    If Left(strLine, 1) = " " Then
      If Left(strLine, 2) = "  " Then
        If Left(strLine, 3) = "   " Then
    ' several hundred more lines here
        Else
          strFilename = arrSplitLine(2)
        End If
      Else
        strFilename = arrSplitLine(1)
      End If
    Else
      strFilename = arrSplitLine(0)
    End If

    Complete with subtle bugs like comparing Left(strLine, 87) to a string with 86 or 88 spaces, and so on.



  • I think it's more like this:

    [code]
    Line1 = file[0].split(212);
    Line2 = file[1].split(211); // Next line might only have 211 spaces before filename
    [/code]



  • @dtech said:

    I think it's more like this:

    <font face="Lucida Console" size="2">

    Line1 = file[0].split(212);

    Line2 = file[1].split(211); // Next line might only have 211 spaces before filename

    </font>

    Poetry in pseudocode. So much painful experience distilled into those few lines.



  • Another senior dev's

    limits exposed.

    VB? TRWTF.



  •  God I hate VB.



  • @jamesn said:

     God I hate VB.

    You shouldn't, you should love it.  It's ease of understanding makes it easy to expose crappy programmers.

    I think there are crappy programmers in every language, no more than any other, VB just makes it easy to see how crappy they are.



  • @TGV said:

    Another senior dev's

    limits exposed.

    VB? TRWTF.

    VB, exposing crappy programmers for over 2 decades.



  • @CarnivorousHippie said:

    His solution was to iterate over each line of the file, identify the target filename, and then iterate over the directory to find the matching filename.

    What exactly do you think happens when you use a language built in "does file exist" function ?

    Of course, depending on the number of filenames he has to process and the size of the directory, the obvious answer is to read it once, and make a hash in memory ... and then compare each file in the list with the hash.

    But to criticize somebody for rolling their own "does file exist" function (by iteration) seems a bit counter intuitive as that's the underlying concept. Without knowledge of the language in question, he might not have had any other choice.

    It's all dependant on the number of items in the list and the number of files to compare with which method will be the most efficient. Horses for courses and all that ...

     



  • @daveime said:

    @CarnivorousHippie said:

    His solution was to iterate over each line of the file, identify the target filename, and then iterate over the directory to find the matching filename.

    What exactly do you think happens when you use a language built in "does file exist" function ?

    Of course, depending on the number of filenames he has to process and the size of the directory, the obvious answer is to read it once, and make a hash in memory ... and then compare each file in the list with the hash.

    But to criticize somebody for rolling their own "does file exist" function (by iteration) seems a bit counter intuitive as that's the underlying concept. Without knowledge of the language in question, he might not have had any other choice.

    It's all dependant on the number of items in the list and the number of files to compare with which method will be the most efficient. Horses for courses and all that ...

     

     

    It's VB and I can guarantee you that Windows does not go iterating through all the files in a directory to find a specific file by name.  

     


  • Discourse touched me in a no-no place

    @KattMan said:

    @TGV said:

    Another senior dev's

    limits exposed.

    VB? TRWTF.

    VB, exposing crappy programmers for over 2 decades.

    VB will expose them, but Haskell will prevent them from doing further damage. They'll be stumped by the first compile error.


  • Being stumped by compile errors:

    I remember with Borlands C compiler giving me a "Suspicious pointer error" with no indication of which pointer it was referencing.

    I always solved it by deleting code and reqriting becuase it was faster then tracking down the problem.  For some reason I got it right the second time around.



  • @DescentJS said:

    @daveime said:

    @CarnivorousHippie said:

    His solution was to iterate over each line of the file, identify the target filename, and then iterate over the directory to find the matching filename.

    What exactly do you think happens when you use a language built in "does file exist" function ?

    Of course, depending on the number of filenames he has to process and the size of the directory, the obvious answer is to read it once, and make a hash in memory ... and then compare each file in the list with the hash.

    But to criticize somebody for rolling their own "does file exist" function (by iteration) seems a bit counter intuitive as that's the underlying concept. Without knowledge of the language in question, he might not have had any other choice.

    It's all dependant on the number of items in the list and the number of files to compare with which method will be the most efficient. Horses for courses and all that ...

     

     

    It's VB and I can guarantee you that Windows does not go iterating through all the files in a directory to find a specific file by name.  

     

    What exactly does VB (or any other programming language) have to do with how the files are stored on the underlying filesystem, and how those files can be searched for a specific filename ?

    On NTFS volumes, yes the filenames (along with all other file metadata) are indexed using B-Trees, so searching is fast. On older FAT volumes, filenames are stored in directory tables, which are not sorted nor indexed, and the only way you are going to find a file is to search through them iteratively until you find the one with the matching name.

    So Windows DOES go iterating through all the files in a directory to find a specific file by name, on any non-NTFS filesystem. In which case, you're always going to be faster to read the directory once, store it in memory as a hash / list / whatever, and then check that for the item you are trying to find.

     



  • @daveime said:

    What exactly does VB (or any other programming language) have to do with how the files are stored on the underlying filesystem, and how those files can be searched for a specific filename ?

    Nothing, you were the one that said that depending on programming language there might not be a built in function, as the PL is VB, there is a built in function and that was what DescenJS meant.
    @daveime said:
    small and rare case that proves I'm right and supersmart

    Ohh, boy, you are going to fit right in



  • That task can be done in like 4 lines of Windows Script Host or Powershell.

    /Here's for stating the obvious!



  •  Wait... If the text is fixed witdth, then it's not supposed to have only 211 spaces before the file name.

     Unless you mean he was looking for 212 actual spaces anywhere (InStr, strstr(), String.IndexOf(), etc.) rather than offset 212 in the line?



  • @Medinoc said:

     Wait... If the text is fixed witdth, then it's not supposed to have only 211 spaces before the file name.

     Unless you mean he was looking for 212 actual spaces anywhere (InStr, strstr(), String.IndexOf(), etc.) rather than offset 212 in the line?

    ding ding ding ding



  •  @Medinoc said:

     Wait... If the text is fixed witdth, then it's not supposed to have only 211 spaces before the file name.

     Unless you mean he was looking for 212 actual spaces anywhere (InStr, strstr(), String.IndexOf(), etc.) rather than offset 212 in the line?

    The filename might be right justifed?

     

         Filename9

       Filename10



    (210 spaces omitted for clarity)

     



  • @dtech said:

    I think it's more like this:

    <font face="Lucida Console" size="2"> Line1 = file[0].split(212); Line2 = file[1].split(211); // Next line might only have 211 spaces before filename </font>

    To make it bullet-proof then the only thing that is needed is a XML config file that contains the number of spaces before each filename.



  • @daveime said:

    But to criticize somebody for rolling their own "does file exist" function (by iteration) seems a bit counter intuitive as that's the underlying concept.

    Clearly the proper way to do it would be to create the file inside a try-catch, and if it fails then it must mean that there was already a file by that name. As an added bonus, this method works faster and faster every time you run it with the same list of files. Excellent way to achieve continuous improvement without changing the code.



  • @KattMan said:

    @TGV said:

    Another senior dev's

    limits exposed.

    VB? TRWTF.

    VB, exposing enabling crappy programmers for over 2 decades.

    FTFY

Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.