Class or object?
-
I understand that using Hungarian notation is nowadays pretty superfluous , however... Should I name class variable "cClass" as a class or "oClass" as an object. Just asking, do not flame me for splitting hair. Cheers Vaclav
Vaclav_Sal wrote:
Should I name class variable "cClass" as a class or "oClass" as an object.
It's completely up to you. What notation helps you to remember what it is?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
I understand that using Hungarian notation is nowadays pretty superfluous , however... Should I name class variable "cClass" as a class or "oClass" as an object. Just asking, do not flame me for splitting hair. Cheers Vaclav
(hmmmm religious topic, my favorite) We do not use prefix or suffix (or hungarian notation) for our variable.
class MyClass {};
MyClass myClass;
MyClass* myOtherClass;I'd rather be phishing!
-
I understand that using Hungarian notation is nowadays pretty superfluous , however... Should I name class variable "cClass" as a class or "oClass" as an object. Just asking, do not flame me for splitting hair. Cheers Vaclav
-
this.........+5
-
I understand that using Hungarian notation is nowadays pretty superfluous , however... Should I name class variable "cClass" as a class or "oClass" as an object. Just asking, do not flame me for splitting hair. Cheers Vaclav
In Windows, you'll see "CClass" a lot (capital C as a prefix)... in Linux and a lot of standard libraries, you won't see any indication at all, for them enclosing things properly within namespaces is more important.
-
I understand that using Hungarian notation is nowadays pretty superfluous , however... Should I name class variable "cClass" as a class or "oClass" as an object. Just asking, do not flame me for splitting hair. Cheers Vaclav
If you intend to follow the object-oriented paradigm, then prefixing a variable name with 'o' for 'object' makes about as much sense as prefixing it with 'v' for 'variable'. You might still consider this sensible, to visibly discern them from type names, constants, and functions though. YMMV. As for 'c' (class) prefix, it's often used to distinguish type names from e. g. structs, integral types, enums, etc.. I used (and still use) this a lot, but the longer I think about it the less sense it appears to make: modern editors provide all the information you need by just hovering over the name in question, much more information in fact than you could ever sensibly pack into a prefix. The prefix therefore only carries valuable information if you tend to print out code and prefer analyzing code on paper. Again, not my preference, but YMMV.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
If you intend to follow the object-oriented paradigm, then prefixing a variable name with 'o' for 'object' makes about as much sense as prefixing it with 'v' for 'variable'. You might still consider this sensible, to visibly discern them from type names, constants, and functions though. YMMV. As for 'c' (class) prefix, it's often used to distinguish type names from e. g. structs, integral types, enums, etc.. I used (and still use) this a lot, but the longer I think about it the less sense it appears to make: modern editors provide all the information you need by just hovering over the name in question, much more information in fact than you could ever sensibly pack into a prefix. The prefix therefore only carries valuable information if you tend to print out code and prefer analyzing code on paper. Again, not my preference, but YMMV.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Ok, prefixes for generic objects (like 'o' for objects, or 'v' for variables) are bad notations, but prefixes for variables type make the code more readable, like a story e.g. 'str' for strings, 'n' for numbers, 'arr' for arrays, and so on ... and they are not so hard to type ...
-
Ok, prefixes for generic objects (like 'o' for objects, or 'v' for variables) are bad notations, but prefixes for variables type make the code more readable, like a story e.g. 'str' for strings, 'n' for numbers, 'arr' for arrays, and so on ... and they are not so hard to type ...
You're referring to the incorrect use of hungarian notation. Let me point you to this great article about why it is wrong and how to use it correctly: http://www.joelonsoftware.com/articles/Wrong.html[^] :)
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
You're referring to the incorrect use of hungarian notation. Let me point you to this great article about why it is wrong and how to use it correctly: http://www.joelonsoftware.com/articles/Wrong.html[^] :)
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I understand that using Hungarian notation is nowadays pretty superfluous , however... Should I name class variable "cClass" as a class or "oClass" as an object. Just asking, do not flame me for splitting hair. Cheers Vaclav
I don't use Hungarian these days but oClass seems to have been the more common style (especially in VB). In C++ it was also common not to use Hungarian with objects but just with simple types, integers, floats, etc. In the .NET world Hungarian is discouraged but there is still a widely-used concession to Hungarian with the names of UI controls. btnCustomer, etc., although really we should prefer customerButton.
Kevin