What are the top VFP Nemesis

[jimoo]

I hope to make this a fun topic, but one we can learn from, and because of that, I am asking for this to be a no-star thread.

Here it is.

What is our top VFP Nemesis?

In other words, our top enemies of VFP programming, or things we should not do. Please keep the responses to only VFP programming.

INVALID RESPONSES
COBOL, DOT NET, MAC, LINUX, Etc. - They are not VFP Programming

Valid Responses:
- Hard coding Paths
- Use of .mem files
- Etc...

I can name 10 myself, but I don't just want my thoughts, but a group effort.

I'll start it out with my 1st, but it may not even make our group top 10 (or so) list. Again, a group reply.

My #1 is:
"Hard coded paths"

Also, if they are good - please let the person know that is a good one. A reply is sufficient.


If we have good success, I'll make this into a FAQ (credit the group) for the top 10 things to avoid.

Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[jimoo]

The use of dbc's is almost another thread we should start sometime. I'd like to get everyone's feel on them pro / cons.

As I mentioned, I don't consider them a nemisis, but I have been burned by them in the past so I tend to stay away from them whenever possible.



Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[Mike Lewis]

I guess the nemesis for DBCs would be not keeping track of things, that is, risking the DBC getting out of sync with the indexes or table structures.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[GriffMG]

I have seen some funy things in SQL (the MS one).

Like duplicate keys in the 'unique key' field - you know, the one that SQL generates for you!

Not often, it's meant to be read-only!

Apparently a nested, nested, nested view will allow you to change it!

Regards

Griff
Keep [Smile]ing

 

[GriffMG]

Oh, and Slighthaze...

Don't forget that INSERT works differently for free tables (as opposed to ones in a dbc).

One way slips the record in, the other always just appends

~ 8 )

Regards

Griff
Keep [Smile]ing

 

[GKatReliable]

We still use Fox 2.6a, therefore no OOP.
One thing that drives me nuts is the way my counterpart here writes a .PRG full of procedures. You look at the code, and its DO This and DO That. I am forced to jump up and down the program listing like a pogo stick trying to follow the logic flow. (The PROCEDUREs and FUNCTIONs are at the bottom of the .Prg.) I like to put stuff in the body of the program.
Yes, I know all about putting recurring processing in a PROCEDURE, but one can take this to an extreme and drive the person who has to troubleshoot up the wall sometimes.

 

[GKatReliable]

We still use Fox 2.6a, therefore no OOP.
One thing that drives me nuts is the way my counterpart here writes a .PRG full of procedures. You look at the code, and its DO This and DO That. I am forced to jump up and down the program listing like a pogo stick trying to follow the logic flow. (The PROCEDUREs and FUNCTIONs are at the bottom of the .Prg.) I like to put stuff in the body of the program.
Yes, I know all about putting recurring processing in a PROCEDURE, but one can take this to an extreme and drive the person who has to troubleshoot up the wall sometimes.
What I mean is:
DO WHILE .NOT. EOF()
DO procname
ENDDO
For Pete's sake, just put the code from the procedure up in the main body so I can figure out what's going on.

 

[GriffMG]

GK

I know you meant your example to be extreme, but it really depends on how much code is put in the procedure and whether breaking it down into functions and procedures makes it clearer.

If there are a thousand lines of code, you can generally see sensible sub-sections which can be given explanatory names and perhaps reused.

Or perhaps not!

Regards

Griff
Keep [Smile]ing

 

[jimoo]

GKatReliable

One of the things you will like about moving too VFP 5 or higher is you have the ability to bring up a list of all procuedures / functions within a program and easily navigate to them.

You're point is well taken though, it's not always necessary to write a new procedure of function. My rule of thumb is:

1. If it is going to be called in multiple places.
2. If it is special processing that I want out of the mainline.
3. It is its own seperate routine.

i.e.
SCAN
DO CalcMedical
DO calcDental
DO calcLife
ENDSCAN

Finally, to add to your comment. What bugs me is when I find code that reads:

DO calcMedical and sometimes it is a procedure in the main program, sometimes it is a procedure at the bottom, sometimes it is a procedure in a SET PROCEDURE TO file, and sometimes it is a seperate file.

Here is what I prefer:
DO calcMedical && located at bottom of this program


Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[GriffMG]

Jim

I stick to events and a single procedure file. So any function must be either attached to the object having an event/method or in the procedure file (which IS my main program - if you follow me).

Can get a bit lengthy but makes it simple to find things.



Regards

Griff
Keep [Smile]ing