Hold tight...

This message contains sacrilege - VIEWER DISCRETION IS ADVISED

VFP is NO PLACE FOR HUNGARIAN NOTATION! There, I've said it! (pinch reveal me to be still living).

For those of you in the very dark ages, "Hungarian notation" (don't know where the name comes from) is a 'coding style' where identifiers are PREFIXed by short and specifc letters to denote specific things. These usually (always, to the devout practitioner) "tell" the reader the SCOPE of the variable named and the TYPE of said variable. So, for instance, lcCust has "lc" prefixing Cust, and "l" says it is a local variable and "c" says it is a character variable. Kool!

And it was real cool, all the way through FPD and FPW. But it is totally UNcool in VFP!

Have you noticed that MS recommends the use of Hungarian notation in the docs for VFP 3.0?

BUT, have you noticed that MS doe *NOT* take their own advice - they do *NOT* call their properties cFontName or nFontSize or lFontBold or. . . Why do you suppose this is??

Well, it is because doing so would really gum things up for you and me. Imagine trying to find all of the references or properties for FONTS in the Help if you had to enter "cfont" AND "lfont" and "nfont" and... just to find them. Imagine if the properties/events/methods "box" had some FONT properties under cfont..... and some under ifont..... and some under lfont..... and some.......! Do the same with all of the other properties and see what a mess you end up with!

So WHY DO WE NAME OUR PROPERTIES with HUNGARIAN NOTATION??? There simply is no good reason for doing so with VFP.

1) VFP now allows LONG variable names (up to 120 chars for all except free table field names)

2) VFP has LOTS of *SORTED* lists throughout its development environment.

Why not use a SUFFIX instead of a prefix???

The SUFFIX WOULD DO EXACTLY THE SAME "JOB" AS THE PREFIX (of Hungarian notation) BUT all lists would be in a readable, sensible, CLEAR order which makes for better, cleaner code.

Comments anyone??

Jim (the heretic) N