|
When I pick up a project, I try to be consistent with the conventions already used in that project. If you use different conventions, you have a context switch problem - it can take time to adjust when you come across a section of code with a different convention.
For VB6 apps that usually means the VB style of Hungarian - based only on the physical type of the variable, str for strings. This is virtually a requirement as VB6's type model is so weak - you really do need to know the actual types at the point of use, otherwise you run the risk of making a type error.
For C/C++ code I generally use Hungarian prefixes and try to use more of a logical type prefix in my own code. I don't bother with Hungarian prefixes on structures or objects because the compiler's type checking catches mistakes.
For C# code I don't use prefixes because the type checking is strict enough to catch all type errors I might make. It's also fine to omit prefixes in VB.NET if you've turned on Option Strict.
I don't agree that you should change the style of existing code when you pick up a project. Doing this causes noise in your source control difference/merge tool. I like to review what other people have changed since I last saw a particular file, and I like to review the changes I've made since my baseline. Any change is risky (obviously different changes have different risk levels) and it's preferable not to introduce unnecessary risks. There are generally higher priorities than changing code to conform to what are generally slightly arbitrary standards. If the code is unintelligible, then yes, you may need to rewrite it. On the other hand, if it's unintelligible, you may be unable to understand it sufficiently well to rewrite it successfully.
Objections to Hungarian often include the question of what you do if you change the type of a variable - do you need to rename the variable and all its uses? Firstly this is only a problem if you've encoded the physical type of the variable - int, long, whatever. If you've changed the logical type of the variable, you've changed its meaning, and you need to very carefully review where it's used.
If you're in a non-type-safe environment where you have to encode the physical type of the variable in the name, you need to carefully review every place it's used in order to ensure you haven't introduced a type error. I'm talking about things like silent narrowing conversions as featured in VB6.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
I hate reading hungarian, so when doing a little one-shot program i'll generally not use it. But on something that will be collaborated on/maintained by others, i'll use it to a point, simply because it's our agreed-upon standard.
Interestingly, i have no problem with type prefixing for simple types - p == pointer, str == string, n == int etc. are all easy enough for me to read, provided the writer was consistent (this is also as far as i'll go when writing). But a lot of hungarian code goes much further than this (perhaps it is "correct", i've never seen full docs on hungarian, so can't say). When you get to the point where Intellisense becomes useless as you can't remember all the meta information encoded in front of the variable name, you've shot yourself in the foot - you can't recall the name manually and your tools are useless.
A more insidious problem lies in the false sense of confidence type prefixing can give you when reading someone else's (badly written/maintained) code. I couldn't count the number of times i've run across code passing string pointers in place of BOOLs, or ints in place of doubles... Compiling with a good warning level helps, as does upgrading to the latest versions of VC++ (decent type-checking rocks!). But in the end, people make mistakes, and you can never trust the veracity of a naming scheme when you didn't write the code yourself (if even then...).
Shog9
I'm not the Jack of Diamonds... I'm not the six of spades.
I don't know what you thought; I'm not your astronaut...
|
|
|
|
|
i use Camel for the variables, but use Hungarian for the controls..
so i can declare a variable as:
string mFirstName;
but a Textbox that contains this will be
txtFirstName
|
|
|
|
|
In C# language, I appreciate this practice:
Pascal for publics, Camel for privates, Hungarian for controls. And something like "l_" as the prefix for locals.
(Yes, when I'm going to refactor some stuff, there is more to be changed than just some identifiers ...)
-- Just because you are paranoic doesn't mean that someone isn't after you.
|
|
|
|
|
I like using the 'm_' prefix to destinguish member variables. Limiting the scope and accessibility of variables is a good practice and I don't think it hurts to let future onlookers (including yourself) know that a particular variable is a member variable versus a local variable.
Since I develop software using a variety of languages my casing will vary accordingly.
|
|
|
|
|
Sorry for this question, but what is the difference between a member variable and a local variable? I'm not familiar with this expressions.
|
|
|
|
|
A member variable is a member of a class. A local variable is a variable declared in a function.
class foo
{
public: int m_nSomeStuff;
int PutStuff ( int n )
{
int nOldValue;
nOldValue = m_nSomeStuff;
m_nSomeStuff = n;
return nOldVaule;
}
};
--Mike--
LINKS~! Ericahist | 1ClickPicGrabber | CP SearchBar v2.0.2 | C++ Forum FAQ | You Are Dumb
Strange things are afoot at the U+004B U+20DD
|
|
|
|
|
|
Actually, a local variable is declared within a block.
void myFunc()
{
int nLocal;
if (a == b) {
int nLocal;
...;
}
}
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Because I use hungarian notation in C++ projects but in Java projects I use 'isValid' and 'getSystemData' style.
Igor Urdenko
|
|
|
|
|
I use different formats in different languages. Since each language has different "universally accepted standards," I try to stay close to that standard.
Also, when I'm maintaining previously existing hardware, I try to emulate the coding style of whoever wrote the original software.
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
|
Grimolfr,
Kudos for writing such a creative "clue" SQL ... One correction though ... you forgot the
"[" and "]" around "user". Your statement implies the DB users as opposed to all of the users from your users table. ... Unless you intentionally left out the brackets!!
- Malhar 
|
|
|
|
|
You are correct, and I am duly chastised for publishing untested code to CodeProject. 
But rather than use brackets, I've renamed the table to not conflict with any built-in funtions/constants/objects.
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
|
|
|
In Windows platform, I use Hungarian notation with prefixes. But in Linux, I use c-style notation(because linux is case sensitive).
|
|
|
|
|
Madhu Kampurath wrote:
because linux is case sensitive
Are you implying the VC++ compiler isn't?
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Madhu Kampurath wrote:
in Linux, I use c-style notation(because linux is case sensitive).
so linux compiles ur code ?!? or the gcc or some compiler.
|
|
|
|
|
Can anyone explain to me why some folks including Microsoft are moving away from Hungarian to camel case (or camelCase)? I find Hungarian to be a superior way to annotate my code.
MCSE+I, MCSD, MCDBA
|
|
|
|
|
Phil Sidari wrote:
I find Hungarian to be a superior way to annotate my code.
So do the camelCase people, apparently.
--
My name in Katakana is ヨルゲン.
My name in German is Jörgen.
I blog too now[^]
|
|
|
|
|
C++ typesafety and Intellisense?
--
Meski
|
|
|
|
|
I am a C++ programmer and am a firm believer in Hungarian notation. I don't have an answer for you but I go to a weekly .NET Users group on the Redmond, WA. campus and the comments I have heard from some of the Microsoft employees and contractors there is that they are going away from Hungarian because of inconsistent use (sMyVar or strMyVar for strings, iMyVar or nMyVar for ints) and the improvements that have been made with intellisense.
I agree that it can be a nuisance to decipher someone's Hungarian but once you know the coding style it is nice to be able to quickly read the code without having to stop and wait for the intellisense to pop up showing the variable type.
-Tim
|
|
|
|
|
slimtim wrote:
[...] Microsoft employees and contractors there is that they are going away from Hungarian because of inconsistent use (sMyVar or strMyVar for strings, iMyVar or nMyVar for ints)
Sounds like lack of a consistently applied coding standard and/or guidelines to me. If you have to ask what it means, then it is not consistent or a standard by any means. Inconsistent use is usually not a problem with the standard itself, but with the development staff.
FWIW, my standard uses characters to modify a type, same as when you would declare it, which eliminates some ambigious prefixes, like u. Also, we do not use a prefix to indicate purpose. For example:
<br />
int iSomeVar = 0;<br />
short int siSomeOtherVar = 0;<br />
unsigned int uiStillSomeOtherVar = 0;<br />
DWORD dwValue = 0;<br />
DWORD *dwpAPointer = NULL;<br />
And not:
<br />
unsigned int uSomeVar = 0;<br />
short int sSomeOtherVar = 0;<br />
DWORD cbBufByteLen = 0;
Strings are prefixed with s unless we are using multiple kinds of string objects, like when using both CString and std::string for some reason:
<br />
CString sAString;<br />
CString csACString;<br />
std::string ssAnSTLString;<br />
I could not use Intellisense as an excuse for removing documentation, or not providing documentation, which, IMHO, is what you are doing by removing prefixes. Not everyone that is going to use your code is going to have Intellisense (or something like it).
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites
|
|
|
|
|
You are spot on James! Great examples. I think you summed it up best by saying a lack of coding standards and/or guidleines.
Too bad there isn't a Hungarian Notation Cosortium similar to the W3C.
-Tim
|
|
|
|
|
Hungarian notation is a useful tool - when working in environments that do not enforce type checking (such as scripting languages, etc). Using a prefix can clue you in to what you expect the variable to contain.
In type enforced languages - the compiler will note when you have a type error. It's pretty easy to fix these little bugs so the type notation isn't needed. Also, variable scope should be small enough that it is easy to refer to the declaration, if needed.
However, Hungarian notation has a dark side - and that is that it flies right into the face of encapsulation and data hiding. Of course, there is the contradiction that C++ programmers are the most likely to be the ones using Hungarian notation. Variables should be named for what they represent and not by how they are implemented!
It's also a maintenance issue. In later revisions, a variable could be switched to a different type (that conforms to the semantics of the original type used) - only the declaration and constructor calls would need modification. If Hungarian notation was used - you would have to track down all of the now erroneous prefixes and change them.
I'm really glad that the next generation of programmers won't be seeing the apparent endorsement of this technique in books (at least for .NET).
Dale Thompson
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
