• Zumdahl (unregistered)

    This doesn't really have much to do with this WTF, more like a nugget of knowledge a coworker learned last week, coincidentally dealing with the nontriviality of opening and deleting files. Every file his script created, it was unable to delete. File permissions problem? Ownership problem? Nope. Before calling the delete procedure, he simply needed to set  objFile = nothing. Then the destruction can commence. FYI.

     

  • PHP Coder (unregistered) in reply to Zumdahl

    What does this line do?

    strFile & "2"

  • Gee (unregistered) in reply to PHP Coder

    strFile & "2"

    appends a 2 to the end of the filename

  • Steve (unregistered)

    Now that my mind has stopped boggling... 

    Moral 1: Design before beginning to code. Then actually think it through (may require first learning to think!).

    Moral 2: Do code reviews, they will identify complete idiots (e.g. the one who wrote that), so you can demote them to coffee-fetcher and then retrain them. They will also identify the best programmers.

    Moral 3: Before accepting a new job, ask to see an example of some of the best code they can easily show you.

    Steve

    CAPTCHA: "truthiness" 

  • (cs) in reply to Gee

    Yeah, the strFile & "2" really threw me, since I've never used VB and am used to languages in which the & operator is bitwise-and. It doesn't help, though: the code still hurts, and I'm still not sure what it's supposed to do...

     

  • Andrew (unregistered)

    I don't know VB but I think this is what its doing, in case anyone else is having trouble figuring it out.
    Main loop:
    1. open file
    2. read and make use of first line of file
    3. close file
    4. call delete line
    5. repeat from 1 until file empty

    delete line:
    1. open file
    2. delete something called filename+"2" if it exists
    3. read and discard first line of file
    4. copy all remaining lines to a new file called filename+"2"
    5. close files
    6. overwrite file with the contents of filename+"2"
    7. delete filename + "2"
    return
     

  • Petr Gladkikh (unregistered)

    Well, actually if you wanted this script to be interruptable and work to be done depends only on distinct lines this would have some sense (after processing a line you can stop it and resume later). What damades all the fun (not considering all those unnecessary IO operations) is that there are times when file is completely in memory so interruprion will cause data loss.

    To make this script interruptable just putting an accompanying file with last processed line number would suffice.

    Did I save that genuinely creative programmer from being fired? :)

  • rycamor (unregistered) in reply to Andrew

    That was weird... I was just in the process of writing almost an identical post to yours, Andrew, when Firefox locked up completely. I killed it, came back, and almost did a double-take when I saw your post. I think the Universe 1.0 system just had a resource contention issue.

    Which leads me to... let me guess: this VB application was on a multiuser system with many people potentially reading from the same file. I'm sure there was no chance that user A's filename + "2" could be overwritten by user B's?

    Also, the extreme WTFness and silliness of this makes me think it had to be an important application at a large reputable company, probably involving stock transactions or international money exchange. At least, from what I have seen, this would be par for the course.
     

  • John (unregistered)
    Tim Gallagher:
    What's your moral of the story?

    Don't let the fscking kids near a computer. Hire adults.

  • (cs) in reply to John

    [image]

    i think someone's probably had a bit too much VB. 

  • Brendan (unregistered) in reply to Petr Gladkikh
    Anonymous:

    Well, actually if you wanted this script to be interruptable and work to be done depends only on distinct lines this would have some sense (after processing a line you can stop it and resume later). What damades all the fun (not considering all those unnecessary IO operations) is that there are times when file is completely in memory so interruprion will cause data loss.

    To make this script interruptable just putting an accompanying file with last processed line number would suffice.

    Did I save that genuinely creative programmer from being fired? :)

    I understand the issue when using a shared file, But why dosn't he just lock the file completely (or just deny write acess to the file) when a process/thread has it open.

  • (cs)

    This code opened my eyes.

     

    From now on, I will read books by opening them, reading a page, ripping it out, closing the book and opening it again.

    Or wait, somewhere in between I'm going to copy the book from beginning to end each time. It looks like the program does that at some point, but I couldn't figure out when or why.

  • (cs) in reply to Andrew
    Anonymous:

    I don't know VB but I think this is what its doing, in case anyone else is having trouble figuring it out.
    Main loop:
    1. open file
    2. read and make use of first line of file
    3. close file
    4. call delete line
    5. repeat from 1 until file empty

    delete line:
    1. open file
    2. delete something called filename+"2" if it exists
    3. read and discard first line of file
    4. copy all remaining lines to a new file called filename+"2"
    5. close files
    6. overwrite file with the contents of filename+"2"
    7. delete filename + "2"
    return

    Actually its:

    5. close files.
    6. delete original datafile.
    7. copy tempfile over to datafile.
    8. delete tempfile.

    In a concurrent system, you might actually manage to delete both the datafile and the tempfile, losing whatever you were working on. Indeed a very robust construction.

     

  • Petr Gladkikh (unregistered) in reply to Brendan

    Not necessarily 'shared' file. If it worked that way you could easily just unplug computer's power cord without proper shutdown, reboot it and start this script again. (If operation with lines is at least atomic and durable of course).

  • Luciano Mollea (unregistered)

    four word moral...

    I

    CAN'T

    BELIEVE

    IT

     

  • (cs)

    This looks a lot like what the main loop in one of mine does, only cleaner. I think. Or maybe it's a draw.

    Anyway, here is the SideBar thread for that one.

  • (cs) in reply to Grubsnik

    The moral of the story is: Intensify controlling principles.

     
    Why let an expensive human code something that an underpaid gorilla could do as well?
     

  • Markus Berg (unregistered)
    Tim Gallagher:

    What's your moral of the story?

    The moral of this story concerns the use of goggles, and the fact that they do nothing.
     

  • AndrewVos (unregistered)

    OMG, Delete_Line is a "fix" because the guy didn't know how readline works!!!!!

  • AndrewVos (unregistered) in reply to AndrewVos
    Anonymous:

    OMG, Delete_Line is a "fix" because the guy didn't know how readline works!!!!!

    Ok that was quite obvious. It's early here. I just had my first sip of coffee.

  • M. Smith (unregistered)

    Maybe he wrote it this way so he could re-write it later around bonus time and realize a 5000% performance increase and look like a VB God.

    Then again, a VB God probably has horns and slobbers quite a bit...

     

    CAPTCHA: giggity  

     The Internet Tubes (that what IT really stands for) are powered by a 1.21 giggity-watt Flux Capacitor.  Or so I'm told.

  • My Moral (unregistered)

    At least hire someone who knows how to copy code off of the Internet. I know that gets a bad rap, but a significant portion is better than this sort of thing.

  • gruckiii (unregistered)
    Tim Gallagher:

    What's your moral of the story?



    Do not operate while intoxicated 

  • (cs) in reply to Arancaytar
    Arancaytar:

     From now on, I will read books by opening them, reading a page, ripping it out, closing the book and opening it again.

    Or wait, somewhere in between I'm going to copy the book from beginning to end each time. It looks like the program does that at some point, but I couldn't figure out when or why.

    I've gone ahead and copied this code into my own application - because this is obviously the *best* way to read files, books, newspapers, etc.
     

  • (cs)
    Tim Gallagher:

    Today's Code snippet comes to us from Jeff Miller. He was asked to take a look at a script that was running slowly. This script opened a file and read it in. One of the very first things he noticed was something that was happening with each pass of the loop that read the file.

    He writes, "I noticed first off that the file was being re-opened with each pass of the loop and somehow it was managing to process each line of the file by only using ReadLine."

    It's no surprise that Jeff called this setup "The Fragmenter"

    Sitting innocently near the end of the function was a jewel, waiting to be discovered. The Jewel of the File: Delete_Line.

    Private Sub ProcessFile(strFileName)

    Do Until blnLastTime = True

    Set fileReader = fso.OpenTextFile(strFileName)

    If fileReader.AtEndOfStream = True Then
    blnLastTime = True
    Else
    strTextLine = fileReader.ReadLine
    End If

    ….

    fileReader.Close
    Delete_Line (strFileName)
    Loop
    fileReader.Close

    End Sub



    Private Sub Delete_Line(strFile)

    Set fileReader = fso.OpenTextFile(strFile)

    If fso.FileExists(strFile & "2") Then
    fso.DeleteFile (strFile & "2")
    End If

    Set fileWriter = fso.CreateTextFile(strFile & 2)

    If fileReader.AtEndOfStream = False Then
    fileReader.ReadLine
    End If

    If fileReader.AtEndOfStream = False Then
    strLine = fileReader.ReadAll
    fileWriter.Write (strLine)
    End If


    fileReader.Close
    fileWriter.Close

    fso.DeleteFile strFile, True
    fso.CopyFile strFile & "2", strFile, True
    fso.DeleteFile strFile & 2, True

    End Sub

    Moral of the story? Opening files is never trivial, especially in a loop, but multiple times - heart attack! Also,before calling a function inside a loop, find out what that function does. And... Oh never mind, there are too many to list.

    What's your moral of the story?

    Thank GOD the coder did not write readall and then go through each to find the EOF char to read the line. That will give me multyiple heart attacks same time. :) God help us all...

  • Incen (unregistered) in reply to Arancaytar
    Arancaytar:
    From now on, I will read books by opening them, reading a page, ripping it out, closing the book and opening it again.

    Or wait, somewhere in between I'm going to copy the book from beginning to end each time. It looks like the program does that at some point, but I couldn't figure out when or why.

     

    It makes perfect sense, really, if you're reading in the wind or otherwise difficulties with turning pages. And ripping out pages can really screw with a book's structural strength, so you obviously need to rewrite the entire book (bar the read page) after damaging it. The wind won't be a problem here if you have someone else reading the book out loud to you, and because everyone knows that you lie down ontop of the paper when you write something, thus weighing it down.

    And then you have the other guy copy the book you produced, because you have horrible handwriting and wouldn't be able to read it yourself. And then you can throw away the other 2 books, because they're pretty useless, and proceed to the next page. Really, it's the only way.

     

    CAPTCHA: mustache. Now that I think about it, this did make me feel a little sleazy.

  • (cs) in reply to Incen

    Plus, it's fast as hell.

    And it's not like the CPU or the memory would be doing anything useful anyway. We might as well keep them busy so they don't get bored.

  • Zlodo (unregistered) in reply to John

    Tim Gallagher:
    What's your moral of the story?

    No one working in IT really care about quality.

    The question "what if [xxx] fails?" seems often answered with "who cares". Yesterday, I was digging into a piece of code in our tool that basically loads a bunch of game levels from the local hard disk of the user and save them to our craptastic asset database server, a process we call "commiting".

    If it fails to load one of the levels, it just...

       continue;

    No feedback, no log, nothing. Business as usual. Until, of course, one of our designers complains that he can't seem to be able to commit his changes and I will need to waste two hours digging to find out that someone actually has been lazy enough not to at least log a fucking error message, which takes exactly one line of code.
     

    Somewhat related to the subject, I had the displeasure of having an ATM crash on me yesterday. With my credit card inside.

    It just froze at the screen asking if I wanted a receipt. So I started cursing, hoping that the stupid thing is not so retarded as not to have a watchdog to automatically reset it.

    Apparently, it does. It displayed a message that I couldn't understand as I don't speak norwegian but probably along the lines of "malfunction, we're sorry blah blah".

    Then the stupid thing reset, and instead of doing the non-completely retarded thing and giving me my card back, it vomited me a fucking ticket stating that my card was kept (and probably to go fuck myself and contact my bank).

    The bank that owns the ATM explained me that my card would be retrieved by securitas, and then sent to them, and then to my bank (and it will probably sit on top of some junk of some employee's desk for a few days on several occasions in the process). They actually told me that "getting a new card from your bank should be faster".

    Leave it to the Norwegian institutions to be even more slow witted than their French counterpart, if such a thing is even possible.

    So whenever someone has his shitty, poorly thought out code (unless of course ATM happens to be the one IT market where programmers actually give two shits about their work) crashing in an ATM, you are out of a credit card for weeks.

    /end of random rant of the day. I'm now going to click in the visual studio window and wait for 20 seconds for this marvel of engineering to be ready to accept any command

  • (cs) in reply to Zlodo

    Zlodo,

    <font face="Times New Roman" size="3">You need a drink, my friend!</font>

  • Jason (unregistered) in reply to ParkinT

    Ah, I know the REAL WTF here!

    Inconsistent naming!

    ProcessFile but Delete_Line? WTF!

     

    captcha: clueless - like whoever wrote this code.
     

  • (cs) in reply to Zlodo

    Anonymous:
    Then the stupid thing reset, and instead of doing the non-completely retarded thing and giving me my card back, it vomited me a fucking ticket stating that my card was kept (and probably to go fuck myself and contact my bank).

    Think about this for just a minute and perhaps you'll see why they do it this way.

  • (cs)

    The real WTF is that the person writing the code does not honour the NIH principle. The code relies heavily on instructions that do a lot of work in the background, like ReadAll and CopyFile.

    From the programming style in the ProcessFile subroutine I managed to extrapolate what the code in the Delete_Line subroutine relly should look like:

    Private Sub Delete_Line(strFile)

        Set fileReader = fso.OpenTextFile(strFile)
       
        If fso.FileExists(strFile & "2") Then
            fso.DeleteFile (strFile & "2")
        End If
       
        Set fileWriter = fso.CreateTextFile(strFile & 2)

        If fileReader.AtEndOfStream = False Then
            fileReader.ReadLine
        End If

        If fileReader.AtEndOfStream = False Then

            blnLastTime = False

            Do Until blnLastTime = True

                If fileReader.AtEndOfStream = True Then
                    blnLastTime = False
                Else
                    strLine = fileReader.ReadLine
                    fileWriter.WriteLine (strLine)
                End If

            Loop

        End If

        fileReader.Close
        fileWriter.Close

        fso.DeleteFile strFile, True

        Set fileReader = fso.OpenTextFile(strFile & 2)
        Set fileWriter = fso.CreateTextFile(strFile)

        If fileReader.AtEndOfStream = False Then

            blnLastTime = False

            Do Until blnLastTime = True

                If fileReader.AtEndOfStream = True Then
                    blnLastTime = False
                Else
                    strLine = fileReader.ReadLine
                    fileWriter.WriteLine (strLine)
                End If

            Loop

        End If

        fileReader.Close
        fileWriter.Close

        fso.DeleteFile strFile & 2, True

    End Sub
  • (cs)

    The moral is that there are people who still haven't heard that (systems) Hungarian notation is a bastardized, evil, childish hate-crime against all other coders, or that it has been debunked worldwide as a truly terrible coding practice.  Or that even its inventor and long-time promulgator, Microsoft, has asked people to stop using it.

  • Mojo (unregistered)

    What happened to the "fix this WTF" articles we used to have?

  • (cs)

     

    #! /usr/bin/perl
    open(FILE, 'somefile.txt');
    while (<FILE>) {
       /* do stuff  */
    }

  • Burninator (unregistered)

    Is this part of VSS?

  • Jelmer (unregistered) in reply to My Moral

    Anonymous:
    At least hire someone who knows how to copy code off of the Internet. I know that gets a bad rap, but a significant portion is better than this sort of thing.

    But what if they copy from this site? 

  • (cs) in reply to Zlodo
    Anonymous:
    Yesterday, I was digging into a piece of code in our tool that basically loads a bunch of game levels from the local hard disk of the user and save them to our craptastic asset database server, a process we call "commiting".


    I'm curious, just where is this that you work?
  • Marshall (unregistered)

    YAY!

     

    It''s about time we had more code based WTF's. Thanks a lot 

  • schwomp (unregistered) in reply to benw-24
    benw-24:

     
    #! /usr/bin/perl
    open(FILE, 'somefile.txt');
    while (<FILE>) {
       /* do stuff  */
    }

    No need to close file?

  • magetoo (unregistered) in reply to Zlodo
    Zlodo:

    Somewhat related to the subject, I had the displeasure of having an ATM crash on me yesterday. With my credit card inside.

    [...]

    So whenever someone has his shitty, poorly thought out code (unless of course ATM happens to be the one IT market where programmers actually give two shits about their work) crashing in an ATM, you are out of a credit card for weeks.

    One of the large Swedish banks just changed their name and logo (to the more enterprisey-sounding "Swedbank"). Of course, this means changing the logo in the software that runs on all of the ATMs too. Which runs on Windows.

    Unfortunately, I haven't been able to see the logo in all of its enterprisey goodness recently, since for some reason all of the ATMs I've seen around here seem to have booted up in 16 color mode. And in 16 color mode, the mostly-orange logo is dithered and approximated to some hideous mostly-black blob.

    Clearly, these people know what they are doing. I wouldn't think twice about handing all of my money over to people who have demonstrated such a stellar level of competence. And throwing away all those years of goodwill by changing the name from "Your Good Old Honest Savings Bank" (approximately) to "Faceless Megacorp, Inc, Ltd, S.A." was obviously the right decision too.

    (end rant.)
  • IRRePRESSible (unregistered)

    I'm sorry to say that some of my best coding has been done while being drunk.

    Moral of the story

    1: Don't use VB

    2: If must use VB preferable use narcotic drugs (one would not want to remember the experience)

    3: Monkeys should not program

     

  • (cs) in reply to Arancaytar
    Arancaytar:

    This code opened my eyes.

     

    From now on, I will read books by opening them, reading a page, ripping it out, closing the book and opening it again.

    Or wait, somewhere in between I'm going to copy the book from beginning to end each time. It looks like the program does that at some point, but I couldn't figure out when or why.

    Ah, but that's the true beauty of this code. To keep track of where you are, don't rip pages out. And don't X out pages or use a bookmark. And for God's sake don't simply keep the book open if your going to read each page in one loop anyway.

    No.

    Open Book. Read first page. Close book. Open book. Read first page again (that's the best way to get to the second page). Copy second page through the end of the book to a second book. Close books. Discard first book. Copy cover of first book to second book.

    You are now ready to read the next page in the book.

    No books were damaged in the execution of this algorithm.

    --Rank

     

  • tyen (unregistered) in reply to schwomp
    Anonymous:
    benw-24:

     
    #! /usr/bin/perl
    open(FILE, 'somefile.txt');
    while (<FILE>) {
       /* do stuff  */
    }

    No need to close file?

    nope:

    % strace -eopen,close perl -ne'# do stuff' foo |& tail -3
    open("foo", O_RDONLY|O_LARGEFILE)       = 3
    close(3)                                = 0

    However.  /* do stuff */ is a regex match in perl, not a comment. :) 

  • rycamor (unregistered) in reply to IRRePRESSible

    You people are not using the canonical form for "moral of the story". There is only one moral, and it is told either in a humorous picturesque way or in a sweeping declarative fashion, such as "love is wasted on the egotist". In this case, I think it should go something like this:

    "... and so, the moral of the story is, don't be surprised when a carpenter paints a wall with a hammer."

    or 

    "If you can do the operation in your head faster than the computer can, then the code is wrong."
     

  • Bill (unregistered) in reply to schwomp

    Or die() if the file can't be opened for reading.

  • (cs) in reply to Markus Berg
    Anonymous:
    Tim Gallagher:

    What's your moral of the story?

    The moral of this story concerns the use of goggles, and the fact that they do nothing.



    Anonymous Coward FTW!
  • (cs) in reply to rycamor

    Ingermane to the WTF, but VB makes mine eyeth bleed like a stigmatic statue of the Virgin Mary.

  • (cs)
    Anonymous:

    VGR:
    The moral is that there are people who still haven't heard that (systems) Hungarian notation is a bastardized, evil, childish hate-crime against all other coders, or that it has been debunked worldwide as a truly terrible coding practice.  Or that even its inventor and long-time promulgator, Microsoft, has asked people to stop using it.

    I believe that Hungarian notation is not to be used with properties as stated in your reference: Property Naming Guidelines. 
    I see no reason why it is not beneficial in variable naming.

    Readability.  Readable code is maintainable code.  More readable code is more maintainable code.

    Remember that Internet meme that made the rounds a few years ago, about how words with their letters scrambled remain mostly understandable if their first and last letters are preserved?  When you put garbage characters on the beginning and/or end of your variable names, you undermine that.  Harder to read code is slower to maintain.

    The more your code reads like English (or whatever is the dominant language of your development team), the easier the maintenance, and thus the less costly your maintenance.  And since coders spend between roughly 70% to 90% of their time doing maintenance, that's a significant benefit.

    Here's an example of something that reads like English:

    isLastTime = false;

    See that?  By giving it a name that reads like English, there is no need for Hungarian notation.

    You can do the same for numeric values and strings.  Really, if you have a variable like userName, the type is obvious (and, again, it reads like English).  Something like purchaseAmount is as obvious as it needs to be;  it's a float, a double, or an exact numeric type.  And finally, objects with English names are about as obvious.  A variable like "primaryKeysToDelete" is pretty darn likely to be an array or collection.  A variable like "retailLocation" is likely to be an address.

    And in those cases where it's really necessary to discover a variable's type, declarations are quite easy to find with any modern tool.  I don't even use an IDE;  I know any variable I encounter is a local variable, a method parameter, or a field of the class.  (It could be inherited but that's usually not a sign of good design, and even in that case it's not hard to check the parent classes' fields.)

    So the cost imposed on the bulk of developers' time when you use Hungarian notation comes with very little benefit.

    And while I only cited one reference --- Microsoft's guide to property names --- that doesn't mean it's not prevalent.  I'm not a .NET guy, but I know it's a recommendation in at least one other place.  And I could list a whole bunch of others.

  • Solo (unregistered) in reply to VGR
    VGR:

      And since coders spend between roughly 70% to 90% of their time doing maintenance, that's a significant benefit.

    err... you mean 70% to 90% of their time reading /. a TheDailyWTF.com, right?

     
    captcha: billgates

     

Leave a comment on “The Jewel of the File”

Log In or post as a guest

Replying to comment #99853:

« Return to Article