Hi Walter, a couple of comments:

>- Naming conventions are still usefull in strict typed languages where you have to declare your variables and convert from one to another type when used in functions. But since VFP (and all other Xbase languages for that matter) are not strict typed, it does not seem to make sense anymore.

There are still some situations where it's difficult for the variable name to indicate what Type it is, so for some cases, a prefix will help identify type. Then the next step, of course, is that you have to be consistent, so all variables get a Type prefix. At least where I work, all code must be considered possible legacy code for someone else to have to read at a future date, so a convention is important for that, as well as current developers.

>- Using the 'l' prefix doesn't make much sense to me. In the old day's where JSP (jackson structure programming) was the way to go, and programroutines where very large, it had it's benefit. But when used in routines, methods and event of only a few lines (which is very common in OOP programming) it looks to me that it's more a pain in the *** than it help to clarify the program.

I completely agree, the 'l' is now unnecessary and just clutters up code. I stopped using it long ago. I have a total of zero Publics or Privates in my code now, since I use the TL (and its properties) as an application object. So there are only locals & properties (and lparameters, which I treat as locals, also).

>- When I'm using a for next loop I still write 'FOR nT = 1 TO 10'. Why should I use the n while it's pretty clear that it's numeric. I agree if you have a lot of code in your Loops it could be a help, But then again who writes code in the JSP fashion nowerdays (with VFP)?

I've taken to just using n (FOR n = 1 to 10), so it servers dual purpose as prefix and variable :) For more nesting, n1,n2,etc...But I don't feel using i,j,k,... is bad either, that's what mathematicians always use for index counters, so in statistical programming, it makes sense, also.

>- I did read a lot of other people's code, but i never thought "Well these naming conventions help a great deal to read the code" especially when a variable is called somethink like lnInvDte instead of InvoiceDate. (B.T.W. some programmers used to short each word into 3 caracters because of the 10 caracter limit)

I agree, now that there are both long variables and field names, a good descriptive name is best, even if it's somewhat long.

>- One of the reason why I still use the type prefix is to distinguish variables from field names. but then again, I could use the m. prefix to clarify a memory variable when neccesary.

I strongly dislike the 'm.', it's a relic of the past. I think prefixing variables with n,c, etc, and fields with table names (but no prefixes on either table or field names, which I also dislike) is a good standard, and easy to follow. Using a convention to distinguish view and cursor names from tables is also a good idea. Like all views have suffix 'view', and cursors prefix 'c_', for example...

>- Different programmers use different naming conventions. When you read the other ones programs it can be more confusing than it helps.
>- If a program was programmed by more than one programmer, It really *can* get a mess.

These are true, for sure. But a team should set and document standards, and I don't usually have trouble reading code that has a solid standard to it, once I decipher what the standard is :)