Rational agrument against Hungarian notation?

RiX0R

@asuffield said:

prepBut nI vrbLike adjHungarian! qWhat's artThe adjBig nProblem?

You win this thread.

Hatshepsut

@asuffield said:

prepBut nI vrbLike adjHungarian! qWhat's artThe adjBig nProblem?

Should that be adjsubstHungarian (or substadjHungarian)?

Mikademus

@Hatshepsut said:

@asuffield said:
prepBut nI vrbLike adjHungarian! qWhat's artThe adjBig nProblem?

Should that be adjsubstHungarian (or substadjHungarian)?

Still not specified enough.

"prepBut nppronsubjI vrbpredLike adjsubstobjHungarian! interrogpronpredWhat's artThe adjsubjBig nsubjProblem?"

However, this goes against naïve Hungarian by actually affixing meaning rather than merely superfluous type information to the elements.

jzfredricks

@jsmith said:

Hungarian notation also makes some things a little more cumbersome. Example - a database with 500 stored procedures all starting with "sp". If they started with a range of letters, then it would be easier to navigate the list by typing the first letter in Enterprise Manager.

When using MSFT SQL Server, try not to prefix your user stored procs with 'sp'. (a quick google returns this http://vadivel.blogspot.com/2006/12/dont-start-user-defined-stored.html).

As for HN.. I don't like it anymore. I used to think it was good - "wow, man, you can tell the type just by reading the name". But these days I prefer more concise code. Most of the time I KNOW the type! "strFirstName" is hardly helpful. When would a FirstName be anything BUT a string? If there's any doubt, the IDE will help you.

Anything that makes code easier to READ is good by me, and that includes dropping HN (and most of the time comments :).

The only use I see for HN is when you look at a bit of code for the FIRST time, ie you are new to a project/codebase and are learning your way around. Once you know the code well, HN becomes pointless.

PJH

@Bob Janova said:

I'm going to resurrect this thread to weigh in against Hungarian – or at least the version of it that's commonly used. [...]

There's also the issue of what happens when a variable changes type, which while not common is certainly not unheard of (int to long or int to double happens quite often).

Hungarian should not be used to arbitrarily prefix variables with their native (to the language) datatype - they should be used to describe the type of variable. See http://www.joelonsoftware.com/articles/Wrong.html for a non-trivial example.

aib

Prefixing every variable with its type (or function, or whatever) is too much work for me. Might as well cast everything. (Hey, in the WIN32 API, you have to do both :))

I'd rather use suffixes or otherwise descriptive names.

About scope -- I'm a C guy, so I don't have to deal with temporary variables (much); loop indices are usually i, x, y, etc. or if I'm feeling descriptive, rowIndex, colIndex, etc. ('curRow' or even 'currow' are also favorites in large blocks inside loops, i.e. currow = rows[i]; currow.x = .y = ...) Also, I've recently gained this habit of wrapping my global variables inside structs, so scope is not much of a problem for me. And as for member variables -- can't you tell by the object name beside them? Inside the class itself, I'd rather use this.something than m_something...

While designing tables, I use "iOwner", "iTopic" and such for fkeys that reference the 'id' pkey on another table.. (Maybe that's not a good practice, considering the second part of the name doesn't always match the table name, but it's good to be instantly reminded that it's a foreign key. (I guess, of course, that is the whole point of HN -- but it simply doesn't help me in normal code)

Maybe pFoo for pointers when the function has lots of different pointers and non-pointers with similar names. Foo sourceFoo[256]; Foo *pDestFoo; [parameter] -- but I'd rather redesign the function.

Hold on, I may be on to something: "If you think you need HN, it may be time to break up your function." How about that?

djork

In some code I am working on a class had a bunch of string variables that were prefixed with the Hungarian notation "sz" (which, interestingly, is actually a Hungarian letter). "sz" stands for "string, zero-terminated." The problem is, though, that [b]we're using C# now, moran![/b] You can throw a zero any old place in a .NET string and it will reliably ignore it every time. All it did was stand to obfuscate the code with bizarre consonant combinations and inaccuracies.

Albatross

I've been trying to move away from Hungarian notation, and even using "i" for loops. I found I ended up with big parsing functions that looked like:

For i = 1 to object.count

...

For i2 = 1 to something.count

...

For i3 = 1 to random.count

SomeFunction(i, i3 i2)

Dim i as integer, i2 as integer, i3 as integer, i4 as integer
Dim s as string, s2 as string, s3 as string, s4 as string

So now I just do inline declares:

For Each CustomerID As Integer In CustomerIDs

...

flop

Please, people, read http://www.joelonsoftware.com/articles/Wrong.html for what Hungarian Notation should be used for.

fist_poster

Yes, the article makes a good point.

Yet it made me think of a heretical scheme (which might work in C++, which the author is somwhat angry with). What if I made USString and SString separate classes? What if Request wrapper always returned a USString, RecordSet wrapper accepted both USString and SString and Write wrapper only accepted SString? Then it would be the compiler that would guarantee the correctness of the code (with or without Hungarian) and not just my eyeballs?

ammoQ

@fist-poster said:

Yes, the article makes a good point.
Yet it made me think of a
heretical scheme (which might work in C++, which the author is somwhat
angry with). What if I made USString and SString separate classes? What
if Request wrapper always returned a USString, RecordSet wrapper
accepted both USString and SString and Write wrapper only accepted
SString? Then it would be the compiler that would guarantee the
correctness of the code (with or without Hungarian) and not just my
eyeballs?

Of course you could do that, but then everyone could write safe programs, thus making experts like Joel obsolete.

iwpg

@fist-poster said:

Then it would be the compiler that would guarantee the correctness of the code (with or without Hungarian) and not just my eyeballs?

The compiler? But everyone knows you're supposed to use oh-so-trendy dynamically typed interpreted languages for web development.

asuffield

@iwpg said:

@fist-poster said:
Then it would be the compiler that would guarantee the
correctness of the code (with or without Hungarian) and not just my
eyeballs?
The compiler? But everyone knows you're supposed to use oh-so-trendy dynamically typed interpreted languages for web development.

The trend nowadays is towards not-really-typed-at-all languages, so that you never have any compile errors or run-time type exceptions. After all, if the system doesn't check the types, then it can't fail because of a type error, so that's got to be better.

djork

@asuffield said:

@iwpg said:
@fist-poster said:
Then it would be the compiler that would guarantee the
correctness of the code (with or without Hungarian) and not just my
eyeballs?
The compiler? But everyone knows you're supposed to use oh-so-trendy dynamically typed interpreted languages for web development.
The trend nowadays is towards not-really-typed-at-all languages, so that you never have any compile errors or run-time type exceptions. After all, if the system doesn't check the types, then it can't fail because of a type error, so that's got to be better.

I know you're being a bit sarcastic, but geez. These languages do have coercion exceptions and other ways to handle errors. All you need to concern yourself with is that the argument your function receives can [i]act like[/i] whatever you need. And you're sharp enough to be writing small, testable pieces of code, right?

bstorer

@asuffield said:

@iwpg said:
@fist-poster said:
Then it would be the compiler that would guarantee the
correctness of the code (with or without Hungarian) and not just my
eyeballs?
The compiler? But everyone knows you're supposed to use oh-so-trendy dynamically typed interpreted languages for web development.
The trend nowadays is towards not-really-typed-at-all languages, so that you never have any compile errors or run-time type exceptions. After all, if the system doesn't check the types, then it can't fail because of a type error, so that's got to be better.

After spending so much time with Java's freaking unchecked conversion warnings, Ruby's duck typing was like a magical swan song. It's just so tempting, because I know I'm smarter than the compiler. Maybe, but I'm also vastly more likely to make mistakes.

I still love Ruby, but it's mostly for other reasons. I like duck typing, because it unties my hands (possibly for evil purposes!). But it also shoves a bunch of work into testing that used to be part of compiling. There's always a trade-off.