Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Joel on Software
Message
From
19/05/2005 02:17:15
Walter Meester
HoogkarspelNetherlands
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
01014573
Message ID:
01015707
Views:
52
Hi Cathy,

>I can't believe there's even a debate on this issue. Naming conventions are a MUST as far as I'm concerned. I can easily read my code and the code of others and know what's going on. We also adhere to a strict naming convention for our tables -- each table uses a unique 3-character prefix for all fields in the table. This naming convention makes it EXTREMELY easy to know exactly where a piece of information came from .. and to know exactly what the name of a field is without having to look it up. It really helps with bringing new developers up to speed very quickly.


I have the same practise for tables, just a 3 character prefix and a underscore, so that you can always track where a field comes from and it makes doing joins so much easier.

However this discussion is more about the hungarian notation, where the prefix is indicating type and scope. Since 99% of all variables are (should be) local there is no need to indicate scope unless it is a public or private.

Personally I have never felt that hungarian notation has ever helped me in reading code from myself or others, nor did I ever felt that the ommission of a notation did burden me, so I simply do not get the point.

Also, MS seems to discourage hong. not. in .NET, though I do not know the exact reasons (others might point it out), I can imagine that everyone has its own definition and it really is a mess in seeing so many different naming conventions.


Think about the following:

In a team of developers, it is way easier to apply consistent naming conventions (type and scope notation that is), by having none at all.

It is way easier to just make sure that the name of your variable is easy to understand.

Walter,


>Cathy
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform