![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
OK, I officially hate it.
In this crap codebase, people used a bunch of hungarian notation, then
changed types around without fixing all the names.
So we have bunches of declarations like
char * ulXYZ;
unsigned char ulPDQ;
long* pszABC;
Gah. It's worse than useless noise. It's useless wrong noise, that even
makes the useful noise suspect enough to be useless.
If your IDE isn't good enough to tell you the type of the variable, it's not
good enough to help you rename it when you change the type.
I think the same goes for putting "m" or "g" or whatever in for member or
global variables, etc.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> OK, I officially hate it.
>
> In this crap codebase, people used a bunch of hungarian notation, then
> changed types around without fixing all the names.
Epic, epic failure.
Now I remember why I never liked the Hungarian notation - and I only
ready about it!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> I think the same goes for putting "m" or "g" or whatever in for member or
> global variables, etc.
Why? When I started using those, my own code became much easier to
understand to me months later. When I have code along the lines of:
void Foo::doSomething()
{
mCounter += someValue;
}
or:
void Foo::doSomething()
{
gCounter += someValue;
}
as opposed to:
void Foo::doSomething()
{
counter += someValue;
}
the first two are much clearer than the third one. The third one doesn't
make it clear at all where 'counter' might be defined, while in the first
example it's clear that it's a member variable of the Foo class, and in
the second one it's clear that it's not. In the third one it could be
anything.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 5-6-2010 10:25, Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> I think the same goes for putting "m" or "g" or whatever in for member or
>> global variables, etc.
>
> Why? When I started using those, my own code became much easier to
> understand to me months later. When I have code along the lines of:
>
> void Foo::doSomething()
> {
> mCounter += someValue;
> }
>
> or:
>
> void Foo::doSomething()
> {
> gCounter += someValue;
> }
>
> as opposed to:
>
> void Foo::doSomething()
> {
> counter += someValue;
> }
>
> the first two are much clearer than the third one. The third one doesn't
> make it clear at all where 'counter' might be defined, while in the first
> example it's clear that it's a member variable of the Foo class, and in
> the second one it's clear that it's not. In the third one it could be
> anything.
>
The objection is not to hungarian notation per se*. It is about using it
wrongly. Like any other method of (in-line) documentation, if it does
not match the source it is worse than no documentation at all.
*) though there is the danger that using it without IDE support to
enforce the correct use, will almost certainly lead to mismatches.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
andrel <byt### [at] gmail com> wrote:
> The objection is not to hungarian notation per se*. It is about using it
> wrongly.
That kind of complaint seems kind of moot. Of course if you use any naming
convention wrongly, the code becomes crap. If I do this:
int multiply(int x, int y)
{
return x + y;
}
then that code is crap, of course. It uses the wrong name for what the
function is doing.
Why object about wrong usage of hungarian notation in particular?
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 5-6-2010 16:24, Warp wrote:
> andrel <byt### [at] gmail com> wrote:
>> The objection is not to hungarian notation per se*. It is about using it
>> wrongly.
>
> That kind of complaint seems kind of moot. Of course if you use any naming
> convention wrongly, the code becomes crap. If I do this:
>
> int multiply(int x, int y)
> {
> return x + y;
> }
>
> then that code is crap, of course. It uses the wrong name for what the
> function is doing.
>
> Why object about wrong usage of hungarian notation in particular?
Darren seems to have found a nice collection of them that made his life
a bit less enjoyable.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Why object about wrong usage of hungarian notation in particular?
Because, as I said in the first post, the easiest way to maintain the
hungarian notation correctly is to use an IDE sophisticated enough you don't
need hungarian notation to start with.
It's the same reason people prefer "self-documenting code" over "comments".
And the hungarian notation isn't generally useful enough (especially in
something like C) to warrant going thru the code base to fix it by hand when
you change a declaration.
To be fair, this is the first time I've seen this happen so blatently, but
it's an excellent reason to avoid it in the future. :-)
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> I think the same goes for putting "m" or "g" or whatever in for member or
>> global variables, etc.
>
> Why? When I started using those, my own code became much easier to
> understand to me months later.
For the same reason. When you move it from being a member variable to a
function argument, or from a private member variable to a protected member
variable or a public member variable, you have to go and find and rename
them. And most of the time, it's visual noise.
I far, far prefer taking the 10 seconds at the start to come up with an
unambiguous name that is clear how global the variable is.
Maybe prefixing something with "g" to mean global (altho "s" to be static
might be better?;-) makes some sense, if your program has maybe two or three
actual globals. But for member variables vs arguments vs locals? No, that's
all right in front of you.
And "mCounter" is a member variable of... what class? I have
GameComponent -> DrawableGameComponent -> Boll -> StackableBoll ->
StackableScreen -> UIScreen -> MenuScreen -> OptionScreen -> PlayOptionScreen.
Where in that chain would something as poorly named as "mCounter" be found? :-)
For that matter, where in that chain would you find the static/global
"NextDrawAction"? (Hint, if you just think about what those names might be,
(and knowing that "Boll" is my name for what MVC calls "Controller") there's
really only two likely answers.)
> the first two are much clearer than the third one. The third one doesn't
> make it clear at all where 'counter' might be defined, while in the first
> example it's clear that it's a member variable of the Foo class,
Is it? Or is it a member variable of a base class of the Foo class?
Why would I do that, when I can hover the mouse over the name and have it
come up and say "int Bar::Counter instance variable"? Or click "Go to
definition" to change the type?
Anyway, I'm not saying it's necessarily bad. For one thing, C doesn't let
you invent your own scopes (static, global, member,auto, etc) etc, and
people don't encode the visibility (public, protected, etc) in those names,
so the likelihood of having to change from a function argument to a member
variable, or from a global to an auto is very low.
The other problem with the hungarian stuff is that people will typedef
things, so you have code like
DRM_RESULT result = DO_SOME_DRM_CRAP(pszName, i32Size, ...)
Why does "result" not get a hungarian flag? What flag would you put there?
The whole point of typedeffing DRM_RESULT is to abstract away the type.
As soon as you put hungarian on your variables, you've eliminated the
benefit of typedefs to control the type, which is a far better way of doing it.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> I think the same goes for putting "m" or "g" or whatever in for member or
>> global variables, etc.
>
> Why? When I started using those, my own code became much easier to
> understand to me months later. When I have code along the lines of:
>
> void Foo::doSomething()
> {
> mCounter += someValue;
> }
Oh, also, I'd write this as
this.counter += someValue;
or
Foo::Counter += someValue;
if I thought it needed disambiguation at a particular point.
I often see people do
void SetStuff(int xxx, int yyy, char* zzz)
{
mXxx = xxx;
mYyy = yyy;
mZzz = zzz;
}
where I would either do
this.xxx =xxx;
or I'd give the arguments different names
void SetStuff(int newXxx, int newYyy)
{
xxx = newXxx;
yyy = newYyy;
}
I suggested that to someone who was in the habit of putting m_ and g_ and
such on the fronts of variables, and he started naming every argument with
the word "new" on the front. I don't think he got what I was saying.
The point is to give every variable, even arguments and autos, a name that
indicates their function. Then I almost never need disambiguation.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> Warp wrote:
>> Why object about wrong usage of hungarian notation in particular?
>
> Because, as I said in the first post, the easiest way to maintain the
> hungarian notation correctly is to use an IDE sophisticated enough you
> don't need hungarian notation to start with.
My IDE uses different colors for global variables and member variables.
No need for m_ or g_ if the colors say enough :)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |