Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Is anyone creating new applications
Message
De
21/09/2011 10:19:08
Charlie Schreiner
Myers and Stauffer Consulting
Topeka, Kansas, États-Unis
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
01523984
Message ID:
01524140
Vues:
117
Your post did ellict a chuckle or two. It sounded like a rant from the WTF site.

I remember a developer talking proudly about such a system saying, "nothing's hidden -- it's all in front of you." I wanted to say, "We like things hidden!" That's the beauty of OOP in that we hide everything but the exceptional, which was my point about IF NOT USED('x"). In a modern VFP application, how could that ever be coded? Surely, or as you say, shirley one would have a class that handles that sort of minutia if you were truly an OOP person. I list the tables that are required in a property, I specify any other properties needed to do the work; then I Requery(). If Requery() returns .T., I the work went well and I have my results, whether C/S or Native.

The real problem with such code, and I'm doing a DOS rewrite right now, is that all the data retrieval, calculations, UI stuff, and configuration stuff is all mixed uniformly. I'm glad we know better now and once you break these items apart, it's a beautiful thing.


>Charlie, if you could see the legacy system I am working on now as a hired gun you would be laughing and slapping your thighs. For example --
>
>1. Several page PRGs? Shirley you jest! That's nothing. How about over 10,000 lines? And some of them in methods of alleged classes, not in PRGs.
>
>2. Controlling colors with @ SAY commands.
>
>3. Menus handled the same way. It's like going to a museum.
>
>4. Bonus points: some of the menus have over 20 choices. With over 20 CASE statements to handle the choice, lines of code roaring on page after page like the Mississippi River after a hurricane.
>
>4. There is no standardized method of saving and restoring the environment in a called module. The closest it comes (in some of them) is to save the currently selected work area, its index order, and its record pointer upon entry and restore them upon exit. That is so unreliable given the vagaries of the approximately one bazillion called modules that I was advised to reopen any tables you need under different aliases so you don't F up the calling program.
>
>5. The main form most users work with is so overloaded with functionality, different data being placed at the same spots on the screen depending on the exact menu choices (see above), you can't be sure what's where without firing up the debugger. Colors go bold or plain according to their own inscrutable whims. A given user who doesn't just do the same thing over and over could easily not see the same data layout again the rest of the month. This is pure poetry.
>
>6. The main table in the application -- a DBF, natch -- the table that stores the lifeblood of the entire business, is named the HD table. That stands for Hard Drive. Because it's stored on the hard drive. Actually it's stored on the network now -- onward!
>
>7. The application itself is called by users "the work screen." Because that's where they do their work.
>
>8. Another key table is named AAA.dbf. It stores payments and adjustments, which are differentiated by a type code. Living together like brethren in one table. That whirring sound you hear is Dr. Codd spinning in his grave.
>
>9. Have we mentioned hard coding? Always the first resort. If it's client XYZ and this is a payment and it's within three days of the full moon, and my shoe size is greater than 10, then do one thing. Else do another thing. Always implemented in code. Metadata, who needs it?
>
>Are we having fun yet?
>
>
>>Some of us here do create new applications in VFP, probably a couple per year. The reason isn't intransigence, but necessity. Over the years we have built up a lot of classes for the business domain and we don't have the time to re-create them. We have one client/server app, and will soon have more, but most are against local tables. We use only CursorAdaptors to edit data and only SQL to retrieve data. Our classes are ambivent as to C/S or native.
>>
>>We will be hiring again soon, but I'm not really looking for VFP experience, more for SQL, OOP skills and just good programming talent. I really don't care to see a several page PRG with IF NOT USED('x') and SCAN FOR and a bunch of hungarian notation.
>>
>>
>>>Hi Guys.
>>>
>>>My boss was wondering, of those of us using FoxPro for development, how many are creating new software and how many are only maintaining existing programs?
>>>
>>>Ian Simcock.
Charlie
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform