>- Using naming convention (hungerian for example) is (much) less important than giving good names for a variable.

You make it sound like an either/or situation, and that's not a valid argument. To make code readable, I suggest at least:
1) some sort of naming convention
2) meaningful variable and function names
3) appropriate comments
4) indentation (preferably using spaces)

>- If a variable is named InvoiceDate it's pretty clear that this is of a Date type, so there won't be any use of a variable called ldInvoicedate. the same applies for lnArticleNo, lcAdress.

I am rewriting an application that stores dates in two character field formats ("08/11/99" and "081199"), and this was written in QuickSilver, so all of the Y2Kness of the DBF file format was available but was circumvented. I'm pretty sure that the programmers of this application would still call their variables m.InvoiceDate, even though they were character types.

>- 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.

I've had a ton of problems with values returned from OLE objects that didn't match the documentation. So by looking at the returned value in the debugger I could clearly see that the char value was numeric. For example.

>- On the other hand, Using a prefixes for public or private variable could clearify certain code, although i'm convinced that public variables should be used as less as possible because OOP provides much better way's to handle those cases where most public variables where used.

I agree that public/system variables are a good use of the first letter. But I am confused -- are you suggesting that there should be _two_ naming conventions in use -- one for public/system variables and a different one for local/private variables?

BTW: I've found that there are some places where a variable is simply better than an object reference.

>- 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)?

Single letter variables. I haven't seen those since my Fortran days. They do bring back certain nostalgic memories, especially when trying to figure out nested loops.

>- I did discover a piece of code where there was a variable called 'nRet', but instead of containing a logical value, it was boolean. Talk about confusion....

Now I'm confused. Logical <> Boolean?

>- 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)

... and some programmers used to shorten function names to four characters because Ashton Tate said we could. I agree that it was ugly.

ABTW: InvoiceDat (10 characters). Is that the Date or the Data? <g>

>- 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 agree with this. Some argue that dropping the 'm.' increases the performance of the application, but I like it for the readability (there's no question that it's not a field reference).

>- 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.

And dropping naming conventions is going to make this problem go away?