Comment On The Jewel of the File

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.

strFile & "2"

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" 

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...

 

The moral of the story
is don't drink when writing code especially a language like VB.

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
 

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? :)

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.
 

Tim Gallagher:

What's your moral of the story?

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

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.

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.

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.

 

four word moral...

I

CAN'T

BELIEVE

IT

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.

Anonymous:

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).

I guess you need to
compromise between efficiency and performance(and new hard disk every 6 months) when it comes to data integrity.
 

The moral of the story is: Intensify controlling principles.

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

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.
 

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

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.

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.

Tim Gallagher:

What's your moral of the story?

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.
 

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...

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.

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.

Anonymous:

The moral of the story
is don't drink when writing code especially a language like VB.

 Uhm. How else do you propose to get people to write VB other than getting them drunk?

 
** Martin

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

Zlodo,

You need a drink, my friend!

Ah, I know the REAL WTF here!

Inconsistent naming!

ProcessFile but Delete_Line? WTF!

captcha: clueless - like whoever wrote this code.
 

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.

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

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.

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

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? 

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".

YAY!

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

benw-24:

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

No need to close file?

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.

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

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

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. :) 

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."