|
|
We use Hungarian notation, and I have no problem with that, however there are so many possible permutations that you have to simplify it a bit. I mean I just use small n for *all* numbers, otherwise it gets ridiculously complicated (unsigned int, unsigned long, DWORD, INT64, ... the list is endless). Also, things like lpsz (a long pointer to a zero terminated charcter array) are really silly because all pointers are now long
|
|
|
|
|
By doing this, I think that you miss one of the things that HN is really good at: telling apart similar types. I mean, in 99% of the cases I can tell if a variable is a number or a string from the context and/or the variable name. However, to tell an int from an unsigned int, in most cases I would have to look at the declaration.
|
|
|
|
|
For this question, a radiobutton forced decision is not adequate. I bet that almost everyone uses a certain mix of the styles, and probably noone of the 'Hungarian' voters use the hingatian style in all its glory.
We have a company coding style guide, and this uses a mix of all variations:
locals in 'camel back',
members prefixed with a 'm_', globals prefixed with a 'g_',
pointers are REQUIRED to have a 'p'-prefix,
method names are verbs and Pascal style,
etc...
So I really would have voted all of the choices.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
jhwurmbach wrote:
a radiobutton forced decision is not adequate
Correct. This poll is silly.
The Java convention is "camel" for variable names, "pascal" for class names. In other words, classes start with capital letters.
In my experience, only people used to MFC use "hungarian". Underscores instead of capitalization tend to be used more often by people used to the STL. But...
jhwurmbach wrote:
I bet that almost everyone uses a certain mix of the styles
Yes, especially people that have used more than one language. So again, I agree this poll is silly.
Whatever happended to using variable names that actually make sense?
|
|
|
|
|
... That I do not want to make the language more poor by adding type informations
to my identifier.
Instead, I like to use simple prefixes:
a for attributes
p for method arguments (parameters)
C for class
k for constants
g for globals (like static class attributes)
For me, having a "num" "str" "hwnd" prefixes defeats the purpose of C++ types
I sometimes use T for typedefs or simple structures.
I always use C for class names
I find code much more easy to read this way - except that I am alone to use these
conventions
For local "stack" variables, I use lowercase_underscore_separated identifiers.
When I deal with "complex" expressions, I tend to add a named variable to simplify it.
Sometimes, I disgress by naming local variables in such a way as to repeat it's type.
When I do that, the context usually prooves me right.
...
...
CTracerUtility& tracer = CTracerUtility::Singleton();
...
...
I must confess that my projects (usually huge ones) often contains huge amounts of classes.
I try to write my code with the feeling that even if it is trivial, I must be able to
instantly recognize the intent of the code 6,12 or 18 months later.
Using such a notation helps me a lot. (I write a LOT of code...)
|
|
|
|
|
I have to say, not being a C++er, that that a, p, C, k, g idea is very confusing. Not intuitive at all IMO.
regards,
Paul Watson
Bluegrass
South Africa
Brian Welsch wrote:
"blah blah blah, maybe a potato?" while translating my Afrikaans.
Crikey! ain't life grand?
|
|
|
|
|
a for attributes
p for parameters
k for constants
g for globals
C for class and T for type.
Those are pretty much the only "kind of things" one comes up with.
methods (aka function calls) are pretty obvious with the invocation();
as I mentioned before, I also use "lowercase_underscore_separated" identifiers
for local variable (within the scope of a method / function).
Any C+'er care to comment on this ?
|
|
|
|
|
I have used a similar naming system for a couple of years now and I find it to be very useful. I was originally exposed to it when writing software for the Symbian OS. They have a nice and well thought out way of naming their classes and variables.
Generally I find it that I dont need to read the exact type of the variable (C++ typechecking already enforces this) but that it is more helpful to be able to read things such as the scope of the variable.
|
|
|
|
|
I use Hungarian notation for C++, and camel casing in C#.
Regards
Thomas
Disclaimer: Because of heavy processing requirements, we are currently using some of your unused brain capacity for backup processing. Please ignore any hallucinations, voices or unusual dreams you may experience. Please avoid concentration-intensive tasks until further notice. Thank you.
|
|
|
|
|
underscores and C go together really well, but the only place I use "_" in C# is for global variables.
Really don't see the value in:
private DateTime g_dtCurrent=DateTime.Now();
function DoStuff(){
string l_strMyString = "";
int l_iMyInt = 0;
if(g_dtCurrent > (new DateTime(0,0,0,8,30,0)))
g_willBeLate = true;
}
Cheers,
Simon
sig :: "Don't try to be like Jackie. There is only one Jackie.... Study computers instead.", Jackie Chan on career choices.
article :: animation mechanics in SVG blog:: brokenkeyboards
|
|
|
|
|
A distinction should probably be made between datatype indication conventions and scope conventions.
Anyway, I voted:
Hungarian casing (public=AllCaps, member=smallletters, method-level=m_MemberName)
.NET datatype indicators ( DataTypeCollection, etc)
|
|
|
|
|