- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
jeez whiz, variable naming ... figure it out. It is so helpful to prefix variables and controls. Knowing the difference from sAccount vs. Account (which is a huge class) is wonderful. Knowing the difference between txtAccount vs. dgAccounts is huge.
Stuck doing a bunch of maintenance developing myself, I hate those high school clown coders that stick with txtBox1, input1, a, b etc. Take pride in your work, name your stuff properly and add some green space (comments) to your code. Learn to respect the maintenance developer that has to care for your creations as you move on to hack at more projects. Otherwise I would start looking for your code to be posted on this forum some day.
...venting complete... thank you
Admin
I don't know about you, as the programmer, but I, as the programmer, don't give a [insert culturally appropriate vulgarism] what type of widget created the entry in either the Request_Content or the Query_String. I have the name and the value(s). So a SELECT sent the value this time, so what? I may decide that it's going to a hidden INPUT for page two of the multipage form (without ever interacting with a data repository), and may be modified there. There is NO good reason to memorialize the widget in a name/value pair -- it simply does not matter except in the UI.
Admin
Plus, when your boss decides that pull down list should be a set of radio buttons or checkboxes, you have to go through and rename every reference to that variable.
Admin
You must be misunderstanding someone. I don't recall anyone advocating naming variables txtBox1 or input1. I was thinking "web programming" and someone else was thinking MFC. In MFC, I can see the value of adding the "txt" prefix. In web programming, it's a WTF, useless and breaks the "rules" of separation of application layers. There is no reason a server component should have any clue of what type of HTML widget the user entered the data into. It's irrelevant. Once it does, you are bound to that interface for your application when all the server cares about is the list of name/value pairs passed.
Admin
Ok, the reason you two are not understanding each other, I believe, is because you use a Java architecture and the others are probably using a .NET architecture. With JSP, Servlets the form data is placed in a hash automatically all as a string. All the elements are ultimately a string. With .NET, the elements are treated as objects, so it's very convenient to know what type they are from the name because different functions are available for different form elements. Make sense? Java = hash. .NET = no hash
Admin
redtet - a question on your tagline:
I don't think geek will compile.
Isn't IEarth an interface? Shouldn't geek implement IEarth? It can't be inherited from.
Admin
Aha! I haven't used ASP in over 6 years. She's grown up a little since then hasn't she? Anyway, by default, you're right. Out of the box, J2EE doesn't translate form fields into objects on post/get. Struts, Java Server Faces and other MVC frameworks do, however. But even in this context, on submit, my "Address" validation code still knows that firstName and lastName are strings and zip is a 5 or 9 digit number. Don't get me wrong...I have seen prefixes like strFirstName and intZip, and they can be helpful, but when you bring "sel" (meaning select box) into the mix you lose my support altogether.
Admin
<FONT face="Courier New" size=2>this is the funniest thing i've read all day.</FONT>
Admin
<FONT face="Courier New" size=2>the last time i saw this type of notation in code, it was on my buddy's laptop, which got smaller as it fell down the ravine and vanished from my mind in a puff of desert sand.</FONT>
Admin
see M-/ in emacs
Admin
Normally I would say Hungarian Notation is a matter of personal preference. I personally despise it as a violation of the sacred DRY rule, but others like it. No big deal. Where I draw the line is when the notation is used because the variables are named poorly...
I should hope you don't have an Account.sAccount or Account.Account property. What you really have is an AccountName (or an AccountId?) and an Account. One is a label or a means of identification, and the other is the thing it represents.
Admin
Real programmers use ActiveX plugins for making a screenshot of the form and send it by FTP. Simply submitting the form is for noobs.
(lol)
Admin
Most likely indeed[:^)]
Admin
Remember that MFC/ATL/WTL was back in the days of VC6 (1998? earlier?) and before. It's a perfectly useful and understandable way of creating object oriented c++/win32 apps, as long as the person using it takes the time to learn how to use it properly and doesn't just randomly click their way through the classwizard. MFC was butchered after VC6, and we'll leave it at that.
Admin
In ASP.NET, most client-side form elements have a server-side counterpart within a surrounding "Page" class. Each element then is a member of that page class. So, let's say you want to programmatically set the default value of a drop down list on the server page, you can put a line like "ddlSomeList.SelectedIndex = 2" into the page class code. Similarly, you can set the "default" attribute within the HTML code.
In the case where you write the actualy page code in a language like VB.NET or C#, it might actually be quite useful to prepend each element's name with its type. If you have a form with a lot of form elements, it makes it significantly easier to find a specific element.
Admin
One of the subtleties that might have escaped the coder of this brillant code is that M$IE has a limit of 2083 characters in a URL location box and 2048 characters in the actual GET query (I'm not sure how they manage to have those different...)
http://support.microsoft.com/default.aspx?scid=KB;en-us;q208427
You'd also want to have a pretty fast connection to that server otherwise it would be a nice pain waiting for the form to reload each and everytime you typed something in a box. Ugh.
(Freaking captcha... never works the first time)
Admin
Ah! You said it yourself .... "except for the UI". How about the client-side javascript programmer - you know, the programmer writing the UI? That is the programmer am I refering too .. I recognize that I did not explicitly say that, my bad I suppose. It is handy for THAT programmer to keep track of the actual UI widget-types for the various forms on his or her webpage, I would suppose .... for dumb guys like me, it is anyway.
Like someone else mentioned here, I am normally quite opposed to hungerian notation, except for UI object variable for some reason ... but for scripting languages especially, prefixes are very necessary (especially for function arguments) to make it clear which object type a variable is(or is expected to be).
Admin
It makes easier to translate, for instance.
Translators don't have a WYSIWYG editor for all the crazy file formats programmers come with.
And it matters if something is a button, a label or a title. For instance "Print" is translated into French with "Imprimer" (if it is a command, from user to computer, like a button) and "Impression" if it is some info (label, title).
Admin
The thing is in .NET, you can have something called selSelection in your HTML page, and then if you want to use it in 'codebehind', it must also be called selSelection there. Therefore, if you use prefixes for serverside variables, you have to use them clientside aswell.
Drak
Admin
Maybe to you, Jeff. Not to me. While you are working on the UI, you're supposed to know what controls go on each form. After all, you can see it on the screen any time you want. Right?
See also Stan Rogers's and Arachnid's posts. They made a very good point.
Admin
A busy window with, say, 70 controls... should have been designed as 5 smaller forms from the very beginning. Don't you think?
Admin
THE FACKING PROGRAMMERS CARE DICKFACE!
Admin
Hear, hear
Admin
Most normal thing of the world: Server send HTML-form. User enters incorrect data into a form, submits it; server sends a HTML-page with the same form, highlighting the error. (Or: server uses AJAX to highlight the error without resending the whole page). How can the server do that if he has no idea about the visual representation? I understand that at some level there should be an abstraction, but IMO there must be a first layer on the server which _knows_ the visual representation.There is nothing wrong when a text field is called txtSomething and a list box is called lstSomethingElse in this layer.
Admin
At the risk of getting flamed....isn't this simply client-side code that has been auto-assembled server side by some generic form framework?
The onChange part is propably a generic solution(also designed to work where forms do not neccesarily submit to themselves) to retain the users selection through successive reloads of a form.
Granted for this single example the technique seems overkill and i'm sure there a better way of doing this, but my point is that it's only a real WTF if this is hand-written HTML.
Admin
When the server-side code has to build a form, populating it with the POST or GET data, while keeping the 'data types' of the form fields. Whether a field is a select or a text or a textarea is not sent along with each field, so the only place to store that information is the field name (or the field value, if you're feeling masochistic today).
That's a general example. I'm not sure what kind of real project involves dynamically building a form populated with data sent by the user. Perhaps a final confirmation form that give the user an overview of his filled-in info and a chance to instantly change any mistakes. But I'd handle such a problem differently, for example by inserting tabs for steps, or back/next buttons.
And what kind of application could take the single value from a select and re-insert it as option in a different select? That in itself does not qualify as a reason to Hungarian your fieldnames. Pointless.
In the end, it's all strings anyway -- which makes a fieldname like 'intZip' strange. A form field value is always a string, even checkboxes (in classic ASP, Request.Form('somecheckbox') returns 'on' or type undefined. Not Brillant!, but still very quirky.)
Admin
If it's generated code, you are correct, the WTF is not the author's.
The burden of WTF then shifts to the engineer that created the application that generated this code.
Admin
If and only if it actually adds information. Usually, technical prefixes ad no information because that information is already available elsewhere.
That's why they are declared with different types and your IDE tells you the type when you hover the mouse above the variable name.
Admin
Hypothetically, in your oppinion, how should generated form code look like in order for it not to be a WTF?
I mean, as far as i can see the form will be behave as intended so does it really matter how estetically pleasing it is , as long as it has the desired effect, and you can write nice object code on the server-side like:
$form = new FormGenerator( $dataobject->define() );
$form->draw();
Admin
It could look like hand-coded HTML, so it should look like hand-coded HTML. One can create a formbuilder that stores the raw form info in a database table, and have your language of choice turn it into a working form. There aren't any issues writing the form's HTML that need to be resolved in a "creative" way.
Those two lines of code don't have anything to do with the format of the generated form, so you can write nice code AND have a nice form. :)
Admin
ScirptJockey's what we call them. YAHHHHH!!!!
Admin
If you need your mouse to read code - it sounds like a crutch.
When someone posts to a forum asks why this single line of code doesn't work Account = txtAccount.toString(); I'd have to respond back asking for more info, but if it was written as iAccount = txtAccount.toString(); I'd correctly respond concerning a type mismatch.
- no mouse over needed -
besides, all REAL developers use notepad, a keyboard and preferably the monitor turned off
Admin
Good point -- those stupid UI programmers should not be allowed to do things like name objects in a way that makes sense to them if it forces the server-side code to somehow have to deal with prefixes ... I mean, that is quite true -- it probably takes an extra 1,000 lines of server-side code when the name/value pairs on a form come back with prefixes, causing all kinds of mayhem. Why should we let the lives of the guys writing html/javascript be any eaiser, right? They should be using intellisense and "mouse hover features" and strongly typed variables in their j a v a s c r i p t code anyway, right? (think about that for a minute) Why the need for prefixes!? Those morons! Definitely not worth it for all of the trouble they cause. I know I can't figure out how to write ASP code if the names from a GET come back with prefixes .... it's impossible !
Excellent point, also, about UI programmers -- they should always have everything memorized at all times and always have the entire page/screen always displayed in front of them -- no scrolling or working with the raw HTML / scripting code allowed !! No tricks or naming conventions for them -- those are for wimps, not real programmers !!
Admin
Where did he say it was needed? Oh right. He didn't.
It's pretty amusing when Hungarian Notation supporters point to extremely poor snippets of code that lack supporting context any developer would have, and announce they are the one chosen naming convention. Context is not a crutch. Get over yourselves.
But you're right -- the notation does help a lot when clueless programmers that don't know you can't assign a string to an integer post to forums.
Admin
Problem is that in the current case the so called hungarian notation is used to describe the displayed representation, not it's type...
Oh yeah, because coupling the server-side treatment and the client-side representation of something is very samrt indeed
Hey, why stop here? let's use "txt", "chk" or "lst" for the DB columns where these are stored or to which they correspond, coupling the DB with the client-side representation for the win !
The client side representation does NOT matter, wether it's an input box or a select, no one cares, you get a string anyway, you know what it's supposed to be anyway and you have to make all the fucking checks anyway because anything may be spoofed. All you get from a form is "data", however this data is displayed is none of your concern when you're coding the back end, if it matters in any way then you fucked up when you created the model.
YOU DO NOT CARE !
For fuck's sake, how dumb are you to couple the client and the server that way, are you aiming for the next WTF?
You do not care how the data you send or receive is displayed, the only one concerned is the view layer and it doesn't receive anything, it's merely formatting what the upper layers throw at it! If I get a "username", why should I give a flying fuck whether it's displayed as an inputbox or as a passwordbox on the client? or even as a selectbox? Answer is I don't, I care about variables that make sense and are useful to me, and I name my fields according to THAT problem, I give my fields a name that translates what type of information they send me back, not how they're displayed
And how about just removing the useless prefix from the ID in the first place? It doesn't belong there anyway. It does not make sense in anyway to give a textbox the id "txtMyStupidId", you know it's a textbox, it's written on it for god's sake!
If a javascript coder needs a prefix to know what kind of control he's handling at a given moment, he needs to be shot. Several times. And then moved on to the "VBScript coding" section if you please.
How about it just tests a name,value couple it received against the possible range of this specific value and just sends back wether the name associated to the value fails the test or not? And the client-side JS handler just does it's own magic based on the control name it got back from the server? Does the server need to know anything of the client side implementation? Clearly not. When using Ajax or heavy javascript? Even less so, since you'll probably be mutating or combining form controls via Javascript to ease the user's experience, which means that your selectbox may in fact be displayed as an autocompleting input and that whole form controls may disappear completely and be automagically populated
Admin
Not these days.
Consider a form with 10 menu items, a tab control with 3 tabs, a splitter and 2 panels and a file dialog. That's already 20 controls, and that's just the page structure. Add 10 text boxes and their labels to each tab, and you have 60 more controls, making a total of 80. I don't think that would be considered a cluttered UI.
Admin
That's a sad, angry post my friend ... if prefixes here and there bother you that much, you are in the wrong profession. It's just the way HTML works when you post a form -- the name/value pairs from the name of the element. And to reference an object on a form using a scripting language, you use -- you guessed it! -- the element's name. Just the way it works.
I completely 100% agree with you, that there is no need or value added at all if a GET or a POST has a prefix on the names. And, in fact, I agree even further that it is a bad things because it does imply presentation mixed with data. But that's the way it works, and the "price" you pay if your names come in with prefix -- is it really that bad? Does it really affect things too much on your end?
If it really hurts you that much, and bothers you that much, if it really affects your server-side code that much, you might want to consider a new profession or write the a new internet protocol .... relax .. it will be ok !
We keep joking back and forth about "real programmers" and so on, and guess what: a "real" programmer doesn't cry about the tools they need to use, they don't cry about what the other guy is doing, they deal with it and write good code using what's available to them.
Admin
True. Although I still like to believe the early days of VB(4-6) made it too easy to write shitty code that "just worked." A lot of the samples on the WTF illustrate that.
Before .NET was around, Delphi did a spectacular job at writing good windows and web apps (ISAPI-based) that were fast and fairly lightweight. I still use it and it's been available since the Win 3.11 days and even worked in Win-OS2 (if anybody remembers that stuff).
IDEs have come a long way since Delphi, which set the groundwork for most of today's GUI IDE apps. Anders Hejlsberg and Scott Wiltamuth designed the C# language specification, and most notably, Anders was the principle architect at Borland who designed Delphi's Object Pascal language--which was a break-through since your only option back then to use a OO language to rapidly develop applications was VB (the merits of how OO VB is, is left up to you). Borland C++ Builder only made it a tad easier to put together apps with C++ quickly.
If you ever used Delphi, you will notice in .NET how precisely the exception and event handling model mirrors Delphi, even down to the arguments in the event handlers themselves.
Admin
Not to start more flaming, but I have seen cases where Javascript programmers used the Hungarian identifers in order to loop through all the objects on a page and only touch the ones of a certain "type", such as to uncheck all checkboxes on a page, etc...
But I haven't messed with browser Javascript since the NS4/IE5 days--I hate writing code in script languages.
Admin
Only the retarded ones that don't remember the form elements they just typed in their html.
Admin
VB(3-6) also made it easy to write good code that worked.
Hmm...if the same language & IDE could be used to write bad code, and used to write good code, what's the determining factor? Oh, right, the programmer.
I am sick and fucking tired of people bashing VB because "it made it easy to write bad code". As this forum proves, any idiot can write crappy code in any language. The responsibility for good code is solidly and solely on the programmer.
Admin
How does a prefix 'keep the data types' of form fields? Is there some dynamic casting that happens based on whether there is a "txt", "sel" or "int" prefixing the attribute name? It just helps a code monkey remember something that, if he were good, he should remember to begin with.
Admin
Nice one ... very clever response to a post that clearly needed responding to.
There are *some* programmers out there that have to deal with more than "hello, world" web pages, you know .... you can't assume that everyone else deals with apps as simple as the stuff you get to work on.
Does it really affect you that much? Why so angry? What happened in the past? Did you try to write an ASP page one day that accepted input from a form and you couldn't figure out how to handle the prefix? Tell us your story so we can learn and maybe it will be therapetic for you!
It's amazing the responses and the angry statements being made about this -- it really, really bothers people I guess. It's a great way to show your superiority to other programmers, I suppose, by nitpicking over things that they might do to help themselves feel more comfortable with their code or to help with their memory.
It's one thing if something someone is doing causes you more work (i.e., some of those database "designs" out there ...) but does this really affect you one way or another? How much productivity is lost when a form's names have prefixes?
Admin
Yeah, just get it running as desired and go hide under your desk, since, once it's running as desired, no one will ever have to touch it again. This is a terrible phenomenon that's spreading through the indistry called "WTF and forget".
Admin
That's a bit of a WTF. The type is an attribute fully accessible from your JS. I have a simple utility function that does just that, actually:
DocumentUtil.getElementsByTagNameAndType = function (tagName, type) {
var elementsWithTag = document.getElementsByTagName(tagName);
var matches = new Array(0);
for (var i = 0; i < elementsWithTag.length; i++) {
if (elementsWithTag[i].type == type)
matches.push(elementsWithTag[i]);
}
return matches;
}
But I'm no JS expert.
Admin
To be clear, Java developers ALWAYS use hungarian notation if they follow the suggested Sun Java coding standards. They should't, and often don't in my experience, use poitless prefixes as a crutch.
Admin
I understand your approach but do I really want to rely so heavy on client-side scripting? What if the user is not using a full-powered PC, but a Smartphone? Call me old-fashioned, but my mental picture of a web application includes a really dumb browser talking to a representation aware layer on the server side - one that knows the text fields and lists - which in turn talks to other layers, not necessarily on the same server, which handle the business logic, persistence etc. I don't like the idea on doing too much in the browser; you might end up with a C/S-like application model, only much more complex.
Admin
C'mon, that's just a big juicy WTF. It has nothing to do with the discussion at hand.
The DOM has collections like document.images and document.GetElementsByTagName("img") that make this trivial. Using a naming convention as anthyting more than a mnemonic device to make the programmer's job (even a little bit) easier is a "bad thing".
Admin
<FONT face="Courier New" size=2>i completely disagree. though i completely distance myself from GUI programming (web app or otherwise), i can say some things about generated code. i see no value in wasting time making generated code look human-readable. you may want to do this initially, in order to make debugging the generated code easier.</FONT>
<FONT face="Courier New" size=2>still, i question the approach of generating code to make a form dynamically out of a data object. seems like there are better constructs for this, though i'm admittedly not well read on them.</FONT>
Admin
You must be a gui programmer, who doesn't know how HTML does in fact work and has absolutely no clue of the concept of decoupling. Is it HTML that requires you to prefix a f-in text box with "txt" or "sel"? Is that how it works? Good god, it troubles me to see that there are so many people doing this when it adds no value. I hope you have your hockey helmet on becasue you're going to hurt yourself.