>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
Well, this is where I doubt......

>2) meaningful variable and function names
I agree 100%

>3) appropriate comments
Well, I've got some thoughts about this too.. But you're right comments should be used to clarify you programs.

>4) indentation (preferably using spaces)
I Prefer TABs

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

Well i this case, it would not hurt... But even in this case, if you know that for whatever reason the datefields where converted to caracter, there is no question about the type of invoicedate. Especially where the scope of a variable is small (I think the large majority nowerdays), I can't see any benefit in using naming conventions.

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

Is using naming conventions going to solve the problem ?

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

I don't see use for a prefix for the local variable, On the other hand I can see the use of public variables (maybe for private) prefixes because they pop in some code not knowing where it came from.

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

I agree, but the times that an app can have many, many public variables are gone. My apps contain only a very few public variables. Marking them with some kind of prefix seems usefull to me though.

>>- 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 agree in the sense that if they are used in large loops, they must have a meaningfull name, but if the loop is just short and has no particular meaning other than a simple counter, why not use the I,J,K, R,S,T, X,Y,Z caracters ? A variable called nCounter doesn't say anything more .....

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

Oops :-) I ment: logical = numeric

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

Well IMHO, dropping naming conventions solves the mess, different programmers make when they all use different naming conventions.

But the real question i'm asking, what's the benefit of using naming conventions ? IMHO it is very small within VFP OOP programs (If your language is strict typed and use JSP programming techniques, naming conventions are definitely usefull). If the benfit within VFP OOP programs is very small.. WHY THE **** DO WE USE THEM ???? They take up memory, You make errors when you type them, it's a very hard to learn to always use them, and actually seem to have a negative impact on readability:

I find lnInvoiceno harder to read than Invoiceno, Telling your mind to skip the first two letters (or translate then into there function) when reading code is very difficult to me and certainly not natural.

When we talk about using naming conventions in fieldnames, you can't use Mixed case names, making it even harder to read.


Walter