Calendar Issue

[RedGrittyBrick]

Why do you think I would propose a different name?

Because I misunderstood what you wrote. I did genuinely wonder if there
was a "better" convention I should consider using.

That variable doesn't have its type in its name, so does not violate the
convention I proposed.

Thanks for clarifying the distinction between type and role.

 

[Martin Gregorie]

Hungarian certainly isn't the end-all, be-all to naming conventions.
But I'm still looking forward to the day when someone who is objecting
to it does so with an informed opinion. It seems everyone takes a look
at the Windows API and thinks that they then know just what Hungarian
is, and all that it can be.

I was using the awful M$ convention commonly known as Hungarian Notation
as an obvious example of the pitfalls of including the type in an
attribute or method name.

I admit that the only examples of it I've seen are MS code or have been
stipulated by project technical managers who obviously think that the MS
form is really good. If you have a reference to a definition that doesn't
follow the M$ naming nastiness I'd be interested to see it.

However, my inclination is and has always been to follow the type of
naming conventions promoted by K&R and especially Kernighan & Pike, where
the name describes what the variable is used for or, for a function or
method, what it does, e.g if it holds an account total its called
account_total, accountTotal or even ACCOUNT-TOTAL depending on language
and independent of variable type. It goes without saying that in COBOL
the same logical variable could have several definitions depending on
whether its in an input screen, database record, print line, etc.

 

[Martin Gregorie]

The Wikipedia article has an adequate discussion:
http://en.wikipedia.org/wiki/Hungarian_notation

Note among the "Notable opinions" that the "Systems" variant is the one
specifically targeted by critics, and that's not really Hungarian
anyway.

Hang about: my example, puiAccountNunber (pointer to an unsigned
integer), is an exact fit with Systems Hungarian and would certainly need
its name changed if the variable was changed to a signed long.

I didn't know he developed it round BCPL, but that figures. I used to
know a bit of it as I translated the General Purpose Macrogenerator
(originally written in BCPL) to Algol 60.

Its origins definitely validate a comment I once heard: that the only
justification for using Systems Hungarian was that it could compensate
for deficiencies in a compiler with piss-poor type checking, since using
it substitutes symbol look-up for type checking. The comment was made
about an early Microsoft C compiler, not a BCPL compiler, but IIRC that
was justified: its type checking WAS crap.

 

[John W Kennedy]

Hang about: my example, puiAccountNunber (pointer to an unsigned
integer), is an exact fit with Systems Hungarian and would certainly need
its name changed if the variable was changed to a signed long.

I didn't know he developed it round BCPL, but that figures. I used to
know a bit of it as I translated the General Purpose Macrogenerator
(originally written in BCPL) to Algol 60.

Its origins definitely validate a comment I once heard: that the only
justification for using Systems Hungarian was that it could compensate
for deficiencies in a compiler with piss-poor type checking, since using
it substitutes symbol look-up for type checking. The comment was made
about an early Microsoft C compiler, not a BCPL compiler, but IIRC that
was justified: its type checking WAS crap.

Similarly, I found it very useful in a language where all pointers were
anonymous.

 

[Martin Gregorie]

Hang on what? Your example is indeed "Systems Hungarian", just as you
say. But as I pointed out, that's not really Hungarian. Basing a poor
opinion of Hungarian on "Systems Hungarian" is incorrect, since the two
are not the same.

Well, the impression I got from an initial reading of the Wikipedia piece
was that the Systems approach came first. This impression was possibly
influenced by the knowledge that the PARC project was largely written in
BCPL, which would tend to put a premium on the Systems flavour.

I do take your point that the Apps flavour adds value if used with
caution (e.g. the safe vs unsafe string issue), though here I prefer the
Last approach to the Hungarian prefix, simply because I think that the
purpose of the variable (which its name should reflect) is more important
that whether its safe or unsafe.

If you want to educate yourself on what Hungarian really is, and _then_
say bad things about it, that seems reasonable to me.

I've seen enough bad examples to think that it does more harm than good
when used by average coders writing applications in a modern, strongly
typed language, though it may be useful in Perl or awk scripts.

I don't think it offers anything to Java programming or, for that matter,
the pseudo-object style I generally use for C.