Did I St-St-Stutter?
-
<asp:PlaceHolder runat="server" ID="phPhone">
(Code to Insert Phone Number)
</asp:PlaceHolder>I still use hungarian notation when naming ASP.NET server controls. I hope my coworkers don't think I have a speech im... imp... imped... a speech problem.
Martin Fowler wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Hungarian notation is an abomination before God.
Software Zen:
delete this; -
Hungarian notation is an abomination before God.
Software Zen:
delete this;Gary R. Wheeler wrote:
before God
Wow, I didn't know it was that old! ;P
-
Hungarian notation is an abomination before God.
Software Zen:
delete this;Take that back you heretic! *&pHungarian notation is the way m_objGod s_verbINTENDED us to write code :)
-
I would upvote that thrice if I could :thumbsup:
-
Thank god it was phone, for a moment there I thought you were going to code something else ;)
"You get that on the big jobs."
-
Thank god it was phone, for a moment there I thought you were going to code something else ;)
"You get that on the big jobs."
PHP: Pretty Hot Phone.
Martin Fowler wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
-
Hungarian notation is an abomination before God.
Software Zen:
delete this;Lol, I think it might be with the current generation of compilers, code-completion tools & typesafe frameworks, but back in the early 90's with most development made in C or C++ it really made some sense. At least to me, it was extremely convenient, for example, to figure out instinctively the level of indirection required with pointer operations (I knew instantly when I saw
ppnSomething, that I was manipulating a pointer to an int pointer). After being sold on hungarian, it was hard to work on code that didn't use it, as I had to constantly check declarations and documentation and just felt something was missing. Just my very-debatable opinion. ;) -
AspDotNetDev wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Can't agree with that one. My last employer used "readability" standards that forced us to make the code far less efficient, but more "readable"; the result was performance loss for thousands of users, for the short-term benefit of less-skilled developers (until the project was completed). Better to "inconvenience" a few developers for a short time, and perhaps (horrors!) have them learn new syntax, than to perpetually inconvenience a legion of users.
Timothy CIAN wrote:
the result was performance loss for thousands of users
Presumably this was actually measured and signficant. So what was the measured value? Given that it is easily demonstratable and addressable from the performance point of view. Neither design nor implementation should sacrifice simplicity (understandable implementation) unless it can be first shown that there is in fact a performance impact and one which does impact the usability of the product.
-
Take that back you heretic! *&pHungarian notation is the way m_objGod s_verbINTENDED us to write code :)
Get thee behind me, Satan!
Software Zen:
delete this; -
Lol, I think it might be with the current generation of compilers, code-completion tools & typesafe frameworks, but back in the early 90's with most development made in C or C++ it really made some sense. At least to me, it was extremely convenient, for example, to figure out instinctively the level of indirection required with pointer operations (I knew instantly when I saw
ppnSomething, that I was manipulating a pointer to an int pointer). After being sold on hungarian, it was hard to work on code that didn't use it, as I had to constantly check declarations and documentation and just felt something was missing. Just my very-debatable opinion. ;)I've always hated it, probably because of the occasional stupid moments at Microsoft. A variable would have a 'type' indicated by the Hungarian prefix on the name, but the actual type was something quite different due to tradition or backward compatibility. I've also always thought that making the fact that something was a pointer to a type part of the type name was idiotic. It's like making the addition operator part of the name of an integer.
Software Zen:
delete this; -
<asp:PlaceHolder runat="server" ID="phPhone">
(Code to Insert Phone Number)
</asp:PlaceHolder>I still use hungarian notation when naming ASP.NET server controls. I hope my coworkers don't think I have a speech im... imp... imped... a speech problem.
Martin Fowler wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
-
I've always hated it, probably because of the occasional stupid moments at Microsoft. A variable would have a 'type' indicated by the Hungarian prefix on the name, but the actual type was something quite different due to tradition or backward compatibility. I've also always thought that making the fact that something was a pointer to a type part of the type name was idiotic. It's like making the addition operator part of the name of an integer.
Software Zen:
delete this;ROFL I know exactly what you mean. Stuff like WPARAM and LPARAM being both 32 bit integers... X| I still think that the 'p' prefix to pointer variables was clever, if only to make your brain switch to pointer-awareness coding effortlesly upon variable usage. That's where I see its primary advantage (if not, arguably, the only one) I also hated the different flavors of hungarian. Everyone I know that uses/used it has their own conventions defeating one of its primary purposes. :)
-
I can't understand the dislike of Hungarian notation. I use it; I find it very helpful - couple of letters tells me a lot. I've read arguments against it and I just don't understand.
I only use Hungarian notation with control names. See here. I suppose I just do it because I was taught to do it. However, there are some useful aspects of doing it this way. For one, controls are a bit of a special case, because there can be many controls on a form (Web Form or Windows Form). Giving prefixes based on control type can help dichotomize the collection of controls. That can be useful, for example, when using Intellisense... you can type "lbl" and see a list of all labels on the form. Also, control names tend to conflict with variable names. So you might have a firstName variable and a firstName control. Making the name txtFirstName instead is an easy way to differentiate the control name from the variable name. And then there is the fact that there may be several controls on a form that share the same name (e.g., lblFirstName, txtFirstName, valFirstName... a label, a textbox, and a validator for the textbox). I suppose I find Hungarian notation acceptable when interacting with designer generated code (if it were not designer generated, I might have a FirstName property with a Label/Textbox/Validator subproperty). Hungarian notation in typical code just looks unclean. Much of the time the classes are so specific that the prefix is nearly meaningless and requires unnecessary typing. Not to mention variables/properties will typically be located at the top of the current method, parameter list, or at the top of the class. Easy enough to look at and, if the class is designed properly, there should not be too many of them.
Martin Fowler wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
-
<asp:PlaceHolder runat="server" ID="phPhone">
(Code to Insert Phone Number)
</asp:PlaceHolder>I still use hungarian notation when naming ASP.NET server controls. I hope my coworkers don't think I have a speech im... imp... imped... a speech problem.
Martin Fowler wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
IMHO Hungarian notation used to make sense in ancient times when IDEs didn't provide information about the type and you had to navigate through code to find it. Don't get me wrong, I used it as well. A real problem with Hungarian notation begins when you decide to change the type and forget that the name has to be changed as well. How many times have you worked with code of someone who actually forgot to change the name? It's not only misleading, it's irritating. Personally I use these naming conventions not only in my .Net code but in C/C++ as well.
modified on Tuesday, July 26, 2011 2:33 AM
-
IMHO Hungarian notation used to make sense in ancient times when IDEs didn't provide information about the type and you had to navigate through code to find it. Don't get me wrong, I used it as well. A real problem with Hungarian notation begins when you decide to change the type and forget that the name has to be changed as well. How many times have you worked with code of someone who actually forgot to change the name? It's not only misleading, it's irritating. Personally I use these naming conventions not only in my .Net code but in C/C++ as well.
modified on Tuesday, July 26, 2011 2:33 AM
Did you see the section on "Controls on Forms"? Looks like a mild form of Hungarian notation. Instead of naming after the particular control type, looks like the recommendation on that page is to name it after its function (e.g., field, label, command). That solves the issue of changing control type, at least for the most part (so if you change your control from a textbox to a RichTextBox, "BiographyField" is still a valid name). I like that.
Martin Fowler wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
-
Did you see the section on "Controls on Forms"? Looks like a mild form of Hungarian notation. Instead of naming after the particular control type, looks like the recommendation on that page is to name it after its function (e.g., field, label, command). That solves the issue of changing control type, at least for the most part (so if you change your control from a textbox to a RichTextBox, "BiographyField" is still a valid name). I like that.
Martin Fowler wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
-
<asp:PlaceHolder runat="server" ID="phPhone">
(Code to Insert Phone Number)
</asp:PlaceHolder>I still use hungarian notation when naming ASP.NET server controls. I hope my coworkers don't think I have a speech im... imp... imped... a speech problem.
Martin Fowler wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
This is your phone. This is your phPhone on acid.
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson My comedy.
-
Hungarian notation is an abomination before God.
Software Zen:
delete this;Good thing I'm an atheist then. :laugh:
-- Kein Mitleid Für Die Mehrheit
-
Good thing I'm an atheist then. :laugh:
-- Kein Mitleid Für Die Mehrheit
Hungarian notation is an abomination before all-sentient-life-regardless-of-personal-belief-system. FTFY.
Software Zen:
delete this; -
Performance is a feature. You shouldn't sacrifice performance (where it is actually important) for better readability. However, you should still strive to make the code as understandable (and readable) as possible.
Martin Fowler wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Exactly! It's very truly said! :thumbsup: