Page 2 of 2
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 4:01 am
by Christopher
matthijs wrote:Why are so few people using Hungarian notation anyway?
Because as Linus Torvalds says, it's "brain damaged."
Languages deal nicely with type issues, each in their own way. Spolsky is specifically talking about C (as is Torvalds). I doubt that "the wrong type variable" is very high on the list for any PHP programmer's problems. These rare conditions like safe/unsafe string that Spolsky makes a big deal about should really be handled directly. The idea of spending time entering and maintaining cryptic prefix abbreviations to make these problems apparently obvious is only exciting for a chosen few.
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 4:15 am
by onion2k
arborint wrote:These rare conditions like safe/unsafe string that Spolsky makes a big deal about should really be handled directly.
What do you mean?
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 5:37 am
by Jenk
Meh.. descriptive naming is all I care about. Otherwise do what you like. As long as it behaves how I expect it to, I don't care if it's lowercase, uppercase, underscore, camel cased, whatever.
Much ado about nothing.
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 5:58 am
by onion2k
Jenk wrote:Meh.. descriptive naming is all I care about. Otherwise do what you like. As long as it behaves how I expect it to, I don't care if it's lowercase, uppercase, underscore, camel cased, whatever.
Much ado about nothing.
If you're working as part of a large team, especially if they're distributed across several locations, having a coding standard makes things a great deal easier.
But..
Yeah, I agree. It's something that shouldn't be an issue. In fact, every time I read these discussions about coding standards I wonder if there isn't a way to automate most of the stuff that they impose rules for. Certainly indentation, brace style, and comment style could be rewritten easily by a script. Rewriting variable names would be a little more complicated (moreso if the script uses dynamic names), and I'm not sure you could really rewrite variable names to enfore camelCase (maybe with a dictionary and/or some sort of heuristics?), but still, it might be possible.
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 6:18 am
by volomike
arborint wrote:matthijs wrote:Why are so few people using Hungarian notation anyway?
Because as Linus Torvalds says, it's "brain damaged."
Languages deal nicely with type issues, each in their own way. Spolsky is specifically talking about C (as is Torvalds). I doubt that "the wrong type variable" is very high on the list for any PHP programmer's problems. These rare conditions like safe/unsafe string that Spolsky makes a big deal about should really be handled directly. The idea of spending time entering and maintaining cryptic prefix abbreviations to make these problems apparently obvious is only exciting for a chosen few.
That's why my variable naming convention (listed above in thread) is "close enough".
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 6:44 am
by jayshields
I agree with the "much ado about nothing" points. Especially in the case of PHP where variables can change their types freely. Another reason why PHP is poor ground for Hungarian notation is functions like array_search() which return "mixed".
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 8:21 am
by onion2k
jayshields wrote:I agree with the "much ado about nothing" points. Especially in the case of PHP where variables can change their types freely. Another reason why PHP is poor ground for Hungarian notation is functions like array_search() which return "mixed".
That's the thing that Joel Spolsky highlights in his article though - Hungarian notation shouldn't be telling you to the
type of a variable, but the
meaning of the variable. Once you understand that such notation is very useful.
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 8:34 am
by volomike
jayshields wrote:I agree with the "much ado about nothing" points. Especially in the case of PHP where variables can change their types freely. Another reason why PHP is poor ground for Hungarian notation is functions like array_search() which return "mixed".
My feeling on this is that something is better than nothing. I mean, look at these variables:
$result
$compoundAverage
$msgs
Let's say you're joining a project and they don't have time to tell you everything about the code you'll be inheriting, and have a tight deadline. Wouldn't it be easier for you if you knew what kinds of things were stored in those variables without having to dump them out with die() or var_dump()?
On the mixed item, I use either $mixed or $vResult to indicate it's a mixed result. The "v" means variant or any/mixed. However, I don't let the value sit in $mixed forever -- I convert it to something as I might understand the context or might be able to apply a condition on $mixed, and thus I would be back to my lightweight Hungarian again as something like $sResult (string) or $asItems (array of strings) or $aoItems (array of objects).
And Hungarian doesn't have to be tough -- that's why I came up with a lightweight Hungarian. And in fact, I'm not the only one -- I recently viewed an interactive chat product sold from a guy in Brazil. I cracked open the source and was surprised to see almost my exact same notation used on variables, even with things like $asItems or $aoItems.
So, to me, it isn't a case of
nothing here, but
something, and that something is
clarity. Ask a programmer what his biggest problems are and in the top 5 on that list will be "meeting deadlines". So, with a simple extra keystroke per variable name you help some small amount, then I think it's worth it.
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 12:56 pm
by Christopher
onion2k wrote:That's the thing that Joel Spolsky highlights in his article though - Hungarian notation shouldn't be telling you to the type of a variable, but the meaning of the variable. Once you understand that such notation is very useful.
While I agree with you and Spolsky that the meaning of the variable is what should be made clean, where I (and most others) disagree is that Hungarian Notation is the solution -- or that the the problems of unclear meaning is a big enough problem to require a solution other than occasionally longer names and some comments.
volomike wrote:My feeling on this is that something is better than nothing. ... So, to me, it isn't a case of nothing here, but something, and that something is clarity.
The choice is not between doing nothing and using Hungarian. You present a false dichotomy. The choice is really between using a cryptic coding system everywhere and using longer names just the cases where things are not clear.
volomike wrote:Ask a programmer what his biggest problems are and in the top 5 on that list will be "meeting deadlines". So, with a simple extra keystroke per variable name you help some small amount, then I think it's worth it.
Sorry, "meeting deadlines" is not a programming problem ... it is a symptom of programming problems.
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 8:03 pm
by Jenk
volomike wrote:jayshields wrote:I agree with the "much ado about nothing" points. Especially in the case of PHP where variables can change their types freely. Another reason why PHP is poor ground for Hungarian notation is functions like array_search() which return "mixed".
My feeling on this is that something is better than nothing. I mean, look at these variables:
$result
$compoundAverage
$msgs
Let's say you're joining a project and they don't have time to tell you everything about the code you'll be inheriting, and have a tight deadline. Wouldn't it be easier for you if you knew what kinds of things were stored in those variables without having to dump them out with die() or var_dump()?
On the mixed item, I use either $mixed or $vResult to indicate it's a mixed result. The "v" means variant or any/mixed. However, I don't let the value sit in $mixed forever -- I convert it to something as I might understand the context or might be able to apply a condition on $mixed, and thus I would be back to my lightweight Hungarian again as something like $sResult (string) or $asItems (array of strings) or $aoItems (array of objects).
And Hungarian doesn't have to be tough -- that's why I came up with a lightweight Hungarian. And in fact, I'm not the only one -- I recently viewed an interactive chat product sold from a guy in Brazil. I cracked open the source and was surprised to see almost my exact same notation used on variables, even with things like $asItems or $aoItems.
So, to me, it isn't a case of
nothing here, but
something, and that something is
clarity. Ask a programmer what his biggest problems are and in the top 5 on that list will be "meeting deadlines". So, with a simple extra keystroke per variable name you help some small amount, then I think it's worth it.
Those vars have been taken out of context, and thusly adds bias to your example. However, I can reasonably assume that $result is a query result resource, $compoundAverage is well.. the compound average of something, and $msgs is an array/collection of messages. (note: I'd change it to $messages).
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 8:04 pm
by Jenk
onion2k wrote:Jenk wrote:Meh.. descriptive naming is all I care about. Otherwise do what you like. As long as it behaves how I expect it to, I don't care if it's lowercase, uppercase, underscore, camel cased, whatever.
Much ado about nothing.
If you're working as part of a large team, especially if they're distributed across several locations, having a coding standard makes things a great deal easier.
But..
Yeah, I agree. It's something that shouldn't be an issue. In fact, every time I read these discussions about coding standards I wonder if there isn't a way to automate most of the stuff that they impose rules for. Certainly indentation, brace style, and comment style could be rewritten easily by a script. Rewriting variable names would be a little more complicated (moreso if the script uses dynamic names), and I'm not sure you could really rewrite variable names to enfore camelCase (maybe with a dictionary and/or some sort of heuristics?), but still, it might be possible.
If you are using eclipse.. ctrl+shift+f.
Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Mon Jun 08, 2009 9:05 pm
by Christopher
Jenk wrote:Those vars have been taken out of context, and thusly adds bias to your example. However, I can reasonably assume that $result is a query result resource, $compoundAverage is well.. the compound average of something, and $msgs is an array/collection of messages. (note: I'd change it to $messages).
I agree. I assumed that $msgs was an array because of the plural. But if you need more clarity then call it $messageArray. The the point is to provide meaning as necessary and appropriate to anyone reading the code.
Jenk wrote:If you are using eclipse.. ctrl+shift+f.
I am such an opinionless follower of the status quo the when I auto format in Eclipse or NetBeans it doesn't change my code at all.

Re: Your coding future decided in hilarious, yet acrimonious way
Posted: Tue Jun 09, 2009 11:27 am
by Benjamin
Ah hell. Just use $a, $b, $B, $q, $n and $i or some variant and ensure your job security.