> > Due to time pressures placed upon me I tend to have a slightly selfish relationship with Foxite, only really coming on here when I have reached a dead-end with a problem I need to overcome. Hopefully this is a small amount of payback, it might raise a smile for people who read it.
> >
> > In my time I have come across some terrible code, it isn't always the case that it was written many many years ago but it tends to be the norm or when limitations of the IDE or perhaps laziness of the programmers in question dictated some of the standards of code. I can't think of all the examples, they are numerous, but I did happen across one recently that really made me scratch my head and then chuckle.
> >
> > I came across a piece of code that attempted to remove .CDX files from the data directory of an installation that were no longer required, I don't know why this code was required but it's in there. Despite being written quite poorly the code didn't crash until a very specific occurrence recently. This is the code in question:
> >
> >

> > * gcdir is the full path to the installation, objectname is a field containing table names
> >  SCAN ALL
> >   c = m.gcdir + "data\" + ALLT(objectname)
> >   IF FILE( "&c..dbf" ) AND FILE( "&c..cdx" )
> >    DELETE FILE ( "&c..dxc" )
> >    RENAME ( "&c..cdx" ) TO ( "&c..dxc" )
> >   ENDIF
> >  ENDSCAN
> > 

> >
> > One of my biggest gripes when maintaining other people's code is single letter variable names, I think everyone understands why. One of my colleagues brought an error to me, a 1206 (Recursive macro definition.), on the IF FILE(... line. I had never ever seen a 1206 before so I was baffled as to how code written several years ago and called all the time would suddenly start producing this error.
> >
> > Turns out it was a curiosity of the application path highlighting the poor standard of the code, my colleague had installed the application to C:\B&C\ Obviously the ampersand in the path, followed by the same single character as the variable name was causing VFP to think it needed to evaluate c while it was already evaluating c hence the error I'd never seen before. It took me a while to discover this as even while trying to replicate the error I used a variable called lcApplicationPath rather than just c, since I couldn't bring myself to use a single letter variable name, so my first attempt to replicate failed, I got there in the end.
> >
> > I hasten to add it wasn't me who wrote the code :) nor any of my current colleagues, the culprit has long since gone and we are happy for that, the code has been changed for the better now.
> >
> > Have you any examples of poor or even terrible code that has really left you scrambling for a resolution to a weird error?
>
> Do I really have to tell you?
> Boy I just had to "maintain" code that was so badly written.
> The braindamaged ***hole who wrote this just learned to read and count so it seemed.
> He knew the letter X already so why not use that for every variable X1, X2, X3, X4...
> And even worse, and now you better sit down, he declared each and every variable PUBLIC!!!
> Oh boy, never saw such poor code.
>
> Boudewijn Lutge®ink
> http://www.vfpdevelopers-online.com
> Border Collies, the only breed "That'll do".

Boudewijn,

I know why that fellow no longer develops applications in Holland - he moved to Canada. I spent most of the day trying to figure out that same fellow's code - all X1, X2, X3 ... and ALL public. Two to three pages of code in every event - no methods, just events. He has progressed though. He now uses four character names for his tables - Tbl1, Tbl2, Tbl3 ... but he still uses one letter aliases A, B, C ...

I recommended a complete rewrite. The owner of the company was not pleased. He spent $5K on the application the first time and it took two months to get. I figure it would take that long just to figure out what the fellow was attempting to do. I believe that I can write the thing from scratch in about a week.

Ken
You shall know the truth - and the truth shall set you free. (John 8:33)