Hungarian Notation Flamewar
-
Continuing the discussion from How to increase your LOC count with IDisposable:
Apps Hungarian is awesome.
Apps Hungarian is OK in weakly-typed languages like C, but if you're coding in something strongly typed like C#, it's an imperfect solution where a perfect solution already exists. Supporters of Hungarian often cite the following in support:
Again, this is OK in C. But in C# or other strongly-typed languages, you don't have to rely on wrong code looking wrong; you can make wrong code not compile.
Let the flaming begin!
-
have your hungarian if you want but starting a variable with a $ in a language that does not require it is EVIL and gives me PTSD flashbacks to the days i had to deal with PHP
(apologies to PHP lovers out there. it wasn't PHP's faunt, but that of the apps i had to support)
-
Flamewars category is .... oh.
-
JQuery guys like to use it to indicate that it contains a selector to use with the $ function
-
*twitch*
please.... no more..... :'(
unless of course it's suitably flamy. i have some hotdogs i what to cook and this topic doesn't have enough heat yet.
-
Apps Hungarian
I'm not sure if you don't know what the term is, or whether you're just trolling. Apps Hungarian by definition contains data that cannot be deduced from the datatype - like
byte picKitten[], genomeKitten[]
.I'm not a huge fan of Hungarian both ways, for aesthetic reasons; but it does have its uses where you just can't be arsed to create a derivative strong type for each and every variation of data.
-
-
Hey, the good old BASIC days...
If I remember my BASIC correctly, it suffixed the variable name with a sigil to denote type instead of prefixing it? $ for string, ! for integer, # for double, ...
-
I'm not sure if you don't know what the term is, or whether you're just trolling. Apps Hungarian by definition contains data that cannot be deduced from the datatype - like byte picKitten[], genomeKitten[].
Then fix your damn datatype so it can.
I'm not a huge fan of Hungarian both ways, for aesthetic reasons; but it does have its uses where you just can't be arsed to create a derivative strong type for each and every variation of data.
Creating a derivative strong type takes just one line of code in Ada.
-
it suffixed the variable name with a sigil to denote type instead of prefixing it? $ for string, ! for integer, # for double, ...
So it was, didn't notice that. It even suffixed some functions dealing with characters or strings.
-
Creating a derivative strong type takes just one line of code in Ada.
Well damn, I should migrate all my projects.
-
I hope you like typing. One of the complaints about Ada is that it's verbose on a level rivaling COBOL.
-
have your hungarian if you want but starting a variable with a <kbd>$</kbd> in a language that does not require it is EVIL and gives me PTSD flashbacks to the days i had to deal with PHP
(apologies to PHP lovers out there. it wasn't PHP's faunt, but that of the apps i had to support)
I remember back when I was first getting into programming, I was confused by all the dollar signs everywhere. Learning that sometimes they represented functionality, sometimes they were required for names, and sometimes they meant nothing at all BUT were still thrown in for fun... that kinda turned me off for a while
-
I'm not sure if you don't know what the term is, or whether you're just trolling. Apps Hungarian by definition contains data that cannot be deduced from the datatype - like byte picKitten[], genomeKitten[].
Yeah, but... why would you store a picture in an array of bytes? Why not just... you know... use the Image class?
The WTF here is that in dumb languages like C you have to use an array of bytes to store something that isn't an array of bytes because making your own types is somewhere on the difficult/stupid/impossible scale. C# and other less-stupid languages let you make your own types, so that type of notation is completely obsolete.
I'm not a huge fan of Hungarian both ways, for aesthetic reasons; but it does have its uses where you just can't be arsed to create a derivative strong type for each and every variation of data.
Right; which is the same as saying, "it's only useful in dumb languages for idiots that don't let developers create their own strong types."
-
The WTF here is that in dumb languages like C you have to use an array of bytes to store something that isn't an array of bytes because making your own types is somewhere on the difficult/stupid/impossible scale.
Because [code]typedef struct { byte* pixeldata } Image; [/code] is hard?
-
or even
typedef byte* Image;
if you don't need anything other than the raw bytes.
( of course you should probably have the length ov the byte array in there at minimum, and having things like pixel dimensions could be handy too ;-))
-
Why are you pissy at me? Apparently it's too hard for Maciefegreyr.
-
Except that C typedefs almost entirely (IMO) negate the whole argument of using apps hungarian! Without judgement either way, the argument of apps hungarian is that the type names give you the information that the type system can't check; if you could move that information into the types, then it wouldn't be needed. Except in your example, you haven't really moved that info into the type system, because even though you have two names, the actual type system won't distinguish them. They're basically the same type.
-
-
or even
typedef byte* Image;Actually, @accalia, that one won't work -
[code]typedef byte* Image;[/code] and [code]typedef byte* ZipFile;[/code] can be assigned to each other, where [code]typedef struct { byte* pixeldata } Image;[/code] and [code]typedef struct { byte* compresseddata } ZipFile;[/code] cause compilation errors if you try to do: [code]Image a;
ZipFile b;
a = b; [/code]
-
Why are you pissy at me? Apparently it's too hard for Maciefegreyr.
You do realize they're mocking you and that it's still an array of bytes?
-
hmm fair enough. if you are trying to do strong typing you need the struct.
however if for some crazy reason you only want typehinting (and still allow the void* shenanigans that C is known for) the non struct version will get the job done. (in a WTFY way)
-
So, you're going to subclass everything.
class Count : int { }
class IQLevel : int { }So you don't accidentally put an IQ level in a Count?
-
well i should hope you aren't still using IQ leve. that has been thoroughly debunked as an invalid measurement statistic.
unless they've revalidated it when i wasn't looking.... pretty sure they havent though...
-
People just don't want to be measured.
Now, I agree that IQ needs a LOT more dimensions to it instead of 1.
But the short of it is that they eventually disqualify every form of measuring people. Although they have good intentions, I can't help but wonder, is it just another case of political posturing?
I'm sure it's not. Otherwise, they'd be saying that the education system can't accurately measure people and we need a very convoluted Common Core that makes every kid look equally dumb.
wait...
-
People just don't want to be measured.
QFT.
Now, I agree that IQ needs a LOT more dimensions to it instead of 1.
indeed. to be completely accurate IQ would need a semi-infinite number of dimensions.
for example i'm pretty book smart. i read a lot and think about what i read, but i'm absolute pants at doing algebra long hand. i always end up turning a + into a - or failing to carry the one, or carrying a two by mistake.... something like that. (i'm also fashion sense challenged.... but that's another story)
-
If it takes only one line, and does not have any performance drawbacks, yeah, why not.
-
semi-infinite?
Otherwise, a really large finite number that almost looks infinite.
1/0 is undefined? Nah, just another case of posturing because they defined division by how multiplication works and there's no number times 0 that equals 1.
But that just leaves an infinitely small hole in my graph. It's obvious the value is approaching infinity!
But look at the negative side, it's approaching -infinity, so they don't connect at all.
WTF math!?!?
-
Actually, @accalia, that one won't work -
typedef byte* Image;
and
typedef byte* ZipFile;
can be assigned to each other
Yes, one of C's many WTFs. But couldn't you have a tool (or compiler flag) that checked your code and warned you of those cases?
Or maybe a new keyword. I think someone should start a language that was a superset of C, so you could make slightly less shitty code but was still compatible with what already exists.
-
I just name my damn variables right
Oh look I found some code here.
myCount = someKidIqLevel;
say what?!?!
I don't know if it's right or not, it doesn't have Hungarian?!?!?! Put notation.
Ok?>
intMyCount = intSomeKidIqLevel;
Yeah, that works. It's both Ints see.
Trollalallalalalla.
-
I think someone should start a language that was a superset of C, so you could make slightly less shitty code but was still compatible with what already exists.
There's a D that's more or less what you're after -- C code compiled as D will either work, or fail to compile.
-
Define work?
Does exactly what you coded it to do.
Not related to, Does exactly what you think you coded it to do.
See: "Do what I say, not what I do" as a frustrated retort.
-
That's really nice. I've been meaning to try D for a while now.
-
It'll do the same thing that it would had you run it through a C compiler.
-
-
Best way to describe me.
If the Pyro and sarcasm had a kid together....
...
I would kill it with facepalms
-
If I have an
io.
Writer
, I'm gonna name itw
. If I have av
alue of some type I don't know ahead of time, I'll call itv
.Why would I double or triple the length of my variable names to add zero information?
-
.... because i'm not going to hire you if your variables are single letters? not unless there's a damn good reason for it.
-
-
.... no go for me!
in more ways than one.
-
I just found out the latest version of Go supports NaCl yesterday, and that led me to the discovery that NaCl versions are named pepper_##, where ## is a two digit number. Clever, Google. Very clever.
-
Actually, @accalia, that one won't work -
typedef byte* Image;
and
typedef byte* ZipFile;
can be assigned to each other, where
typedef struct { byte* pixeldata } Image;
and
typedef struct { byte* compresseddata } ZipFile;
cause compilation errors if you try to do:
Image a;
ZipFile b;
a = b;type ( Image1 []byte ZipFile1 []byte Image2 struct{ Data []byte } ZipFile2 struct{ Data []byte } )
Variables of type
Image1
andZipFile1
can be assigned values of type[]byte
, but anImage1
cannot be assigned to aZipFile1
and vice versa.Values of type
struct{ Data []byte }
are assignable to bothImage2
andZipFile2
, but values of typeImage2
cannot be assigned to variables of typeZipFile2
and vice versa.In summary: values with unnamed types (like
[]byte
) can be assigned to variables with named types that are equivalent to the unnamed type (likeImage1
) but not vice versa. Values with named types cannot be assigned to variables with unnamed types.byte
andrune
are aliases ofuint8
andint32
. When a program is compiled, the former are replaced with the latter. These are the only aliases in Go.
-
Mid-flamewar interruption: I've seen code where variables were named in a way where everything the name could tell you, the IDE could do the same.
So code like this:
if (m_CONST_boolRST)
Could tell you that it's a boolean member constant, but not anything about what RST even is.
-
I've seen code where variables were named in a way where everything the name could tell you, the IDE could do the same.
So it was Sys Hungarian? I've got an exco-worker that I wish violence upon every time I need to maintain things written by him as he used a less verbose version of Sys than your example.Specifically things like
[code]
SqlCommand objThingy = new SqlCommand("Stored Procedure Name", objConnectionThingy);
[/code]
-
objThingy
? You used to work with @algorythmics?
-
for (int currentIntegerIndexIntoMyArrayOfFoos = 0; currentIntegerIndexIntoMyArrayOfFoos < myArrayOfFoos.size; currentIntegerIndexIntoMyArrayOfFoos ++)
{
Foo myCurrentFoo = myArrayOfFoos[currentIntegerIndexIntoMyArrayOfFoos];
FrobulizeFooObjectReturnValue myResultFromFrobulizingMyFoo = frobulizeFooObjectAndReturnValue(myCurrentFoo);
}Ugh, Discourse adds a newline every time I paste text into the editor...
-
I....uggggh.
Fucking InstallScript. That shit uses Hungarian notation EXTENSIVELY. I FUCKING HATE IT. I swear that language is the results of a three-way Orgy between C, Pascal and BASIC. That and the fucking "DECLARE ALL THE FUNCTION SCOPE VARIABLES" shit is maddening. You get mentally numb from declaring new functions and making sure you have crap like:
function BlowShitIntoTheRegistry() STRING szKey, szValue, szTemp, szTemp2, szTemp3; INT iRetVal, iFuncVal, iFuckYouSomeOtherVal; begin //DO SOME SHIT return iRetVal; end;
It is a hermaphrodite language trying to be C and BASIC at the same time with some Pascal sprinkles on top.
I just realized I went completely left field with this rant. SEE WHAT HUNGARIAN NOTATION DOES TO THE MIND!
-
.... because i'm not going to hire you if your variables are single letters? not unless there's a damn good reason for it.
for( int helloThisIsTheFirstLoopVaribleFriends = 0; helloThisIsTheFirstLoopVaribleFriends < 100; helloThisIsTheFirstLoopVaribleFriends ++ ){
}
-
well hello there good reason for using the canonical variable
i
withfor
loops!
-
He likes to call people out for pedantic dickweedery but he's not so secretly a huge PD.