- 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
It does effect everyone on the project because it's poor design. If the server component has no interest in the way in which a component is rendered on the client, don't give him any knowledge of it. Though I know it's not true, I'm beginning to think that few people approach design of an application as it is multiple, mutually exclusive, layers.
Admin
It's really just a rarely-used fallback, because most of the time, the declaration is on the same line or a few lines above and thus still visible, and in addition any misuse if types results in compiler errors - which the IDE marks in the code without you having to touch the mouse.
Unless the variable is in fact declared as string and the prefix wrong - which is at least as likely as someone not being able to figure out a type mismatch on their own.
Close, but not quite. "ed is the standard text editor" - and can indeed be (and was) used without a monitor. Ever heard of teleprinter terminals?
But I count myself fortunate to enjoy the benefits of modern IDEs, and will happily admit to not being a REAL programmer. Everyone knows that real is inferior to double, bignum, virtual and irrational anyway.
Admin
Hey, you'll never see any web code I've written that does that! :-) Was this available in NS4/IE5? I remember seeing vary hairy JS code back in those days pre-2000.
Admin
I would correctly respond that you are wrong, iAccount was intended to be an int at one time, but overtime we realized that it needs to be a class that acts like an int in most contexts, but does some complex validation, it supports the operator=(string) (in C++ you can do that)
Of course if is a WTF that we were too lazy to rename iAccount to something else after we did that, and I'm not sure the operator=(string) isn't a WTF, but in the real world both are common enough that you cannot trust that iAccount will be an int.
The correct response is that you need more context to help out. Without knowing how Account is really declared you cannot say anything. Variable names are a clue, but that is all - no compiler enforces them. There is no reason to assume that Account even refers to an account of some type and not a railroad boxcar. (Though death is too good for someone who actually does name things like that)
Besides, if your functions are so long that a single page-up cannot tell you the type of local variables, they need to be split up anyway. (there are exceptions, like long switches, but they should be simple enough otherwise that this doesn't come up)
Admin
Then I'll consider myself lucky.
Admin
Thirteen Ways to Loathe VB: http://www.ddj.com/documents/s=1503/ddj0001vs/jan00.htm
Also See: http://en.wikipedia.org/wiki/Visual_Basic
Hey, the language is useful, the scriptable version is free, and lots of consultants have made money off of it. I'm all for that shiznit.
Admin
getElementByTagName makes trivial the retrieval of a precise node flavour (image, link, division, span, ...), and the access to object members such as "type" allows for easy further checks.
No need for a prefix, it's there and clearly available already
Granted, NS4 and IE5 probably didn't provide such object oriented constructs, but modern javascript scripts are much cleaner, leaner and efficient with them (NS4 only had the document.layers interface, IE4 had document.all and IE5 already had getElementsByTagName & getElementById).
Admin
Hey, I hate VB too. That's not the point. The point is that I don't hate it simply because some other programmer uses it to write shitty apps.
All these issues about VB are known, have best practices specifying how to avoid them and have myriad examples showing how not to do things. The programmers who choose to use VB should be blamed for creating WTFs, not VB itself.
Admin
Agreed. I wonder if Paula still writes (non-writes) VB....
Admin
Really? If someone is not doing their job correctly, you don't point out a better way to them? Who is doing any crying? Giving someone constructive critcism is helpful. Just dealing with problems that are people are creating is a hide your head in the sand approach. Why not be "a real man" and confront the problem? Sure - this whole issue of prefixes vs. no-prefixes might not be that big a deal but you seem to be advocating a hide your head in the sand approach for everything. Just accept what everyone else is doing as something that can't ever be changed and deal with it - even if that means lost productivity and lost dollars.
Boy, I'd love to have you on my team so I could promptly fire you for being spineless.
Admin
Actually, IEarth is a partially implemented abstract base class that the coder incorrectly prefaced with 'I'.
Admin
Uh....I need to go refactor my train simulator
Admin
See?! Prefixes are bad!
Admin
Agreed. Thinking like that leads to yesterday's WTF (the super-duper integration nation).
Admin
I meant 'field types'. *hiccup* Scuseme.
And as said, in client-side Javascript, the field type is a property of the field element node, but in ASP, Request.Form contains no such information; just the value of the field.
Admin
Okay...
On the whole hungarian notation thing: I can see an instance where the programmer would want to know what type the item on the submitted form is: Multi-select lists, becuase they give a list of items selected, instead of a single item, and each server technology interprets that list differently.
Admin
That is beautifully said. Kudos. My REAL truly is no match for the irrational. I will now plug my mouse back in and begin programming again as I am a beaten man.
Admin
True, but even gen 3 browsers supported document.forms[<index or name>].elements[<index or name>] to iterate through or grab an element (field or button), and supported .type and .length (as appropriate) and .name for those top-level elements. There has never been a JavaScript-driven reason for using the widget in a field identifier, so the only possible argument for using the widget type as part of the field name is for non-JS client-side code. And since you can programmatically morph between widgets for the same field without asking the server's permission (or even cc-ing them on your memo of intent), the argument for including the widget in the field name gets even sillier.
And don't get me started on the microbrowser thing -- the thing on the phone submits name=value pairs just like the big boys, and you're even more likely to feed the same data to a different widget on a subsequent form in the micro paradigm, and to have multiple submit points that should be able to use the same data-handling code with a completely different widget set.
Admin
But does this application design imply that these layers have to coincide with the phyiscal machines? Can't you have more than one layer on the server? Does it justify the use of heavily complex, browser-dependend client-side scripting just to make sure the other box (the server) doesn't learn anything about the presentation tier?
Admin
>> If someone is not doing their job correctly, you don't point out a better way to them?
I spend lots of time helping people when it is important, and I often offer advice -- maybe too much sometimes!
>>but you seem to be advocating a hide your head in the sand approach for everything. Just accept what everyone else is doing as something that can't ever be changed and deal with it - even if that means lost productivity and lost dollars.
Can you show me where I said that? How did I imply that? In fact I literally said the complete opposite in one of my posts! Read carefully before responding (especially when you are going to insult someone) and don't put words in people's mouths.
I can picture it if you were my boss : "That Jeff has done it for the last time -- I am terminating him !! Ted wrote an app and he named a variable txtName. And guess what -- Jeff didn't stop him! Jeff didn't complain about it, he didn't whine or cry, he didn't even come to upper management and inform me immediately!! For some reason, Jeff simply said 'not the name I would use, but it doesn't bother me, who I am to judge?' and proceeded to do his own job and write his own code .... we cannot stand for this!"
I don't know whether to be amused or truly scared for the things that people in the IT world waste their time on when I read this thread ....
Admin
Of course you can have more than one layer, but this question was of course rhetorical. I guess I'm not sure where you get 'heavily complex, browser-dependend client-side scripting' from what I said. My position is that you should have limited JavaScript on the client.
Admin
Have you no standards at your company or are you all cowboys? Is this type of prefix part of those standards? If so, your architect or team lead needs to be terminated.
Admin
That'd also stand for checkboxes then, since you can check a whole bugger'o'them and have them all with the same name
Beautifully said
Well, "limited" doesn't say much does it?
I don't think that the amount of javascript matters (as long as it's kept under the "yeah my browser starts crawling & growling and finally painfully dies from JS engine rupture" limit, that is), what really matters is that Javascript stays what it's supposed to be: icing on top of the apple pie. Nice to have, pretty and shiny, tasteful to eat, but removing it doesn't actually harm the pie itself. Javascript should be that unobtrusive, add value through ease of use, chain of events, reload-free checks and all, but never ever necessary for any action.
Admin
ok, as a straw man:
On a web page, I have an input textbox and a label for it. These are to collect a user's last name.
How do I name these intelligently? From what I'm reading here, the following is bad form:
lastNameLabel
lastNameTextBox
But they both can't be lastName, and lastName1 and lastName2 is silly.
Yes, I realize the label's data will not be posted to the server, but I may still want to manipulate it client-side.
Admin
I don't mean to sound condescending at all but, does the label get posted to the server? If not, name that whatever you want.
Admin
I imagine the response would be: "lastNameLabel and lastName" since, in theory the textbox holds the name and the label is just that...a label. I would probably do the following:
lbllastName
txtlastName
lastName
where lastName = txtlastName.text
Yes, prefixes come in handy when talking about the same set of data that has multiple related elements in one layer.
Admin
I stated that it does not get posted, and the whole point of the question is what to name it. I know I can name it whatever I want; the issue is, what is considered an appropriate name?
I want it logically linked to its referent (the textbox), but since it's in the same namespace, it can't have an identical name.
Admin
That's a good example. Here's what I would do without Hungarian Notation:
My prime directive is that a variable should be named by the information it contains. In your label example, you really do have a control which contains a label for a last name, and so the name is accurate. In your textbox example, the contained information is a last name, not a last name textbox, and so the name is changed to reflect this.
In an ASP.Net world, the label is indeed named by the server and stored. Naming labels is particularly useful when localizing your forms.
Admin
Wonderful question. Personally I would name these as mentioned as shown but with prefixes. But I look forward the response from those that have been howlering about this issue.
'What do you want us to to?'
Admin
Ok, now as a logical extension, let's say I have 2 controls, both of which contain last name information, and both of which get posted to the server:
lastNameTextBox
lastNameSelect
(it's contrived, but let's say I have a list of last names to choose from, but you can also type in a new one...)
Now what do I name them?
Admin
As stated, this is how you do it. Unlike form elements, labels relate only to UI, and not the data in the text field next to it, so there is no concern that you will have to deal with a variable named txtLastName all the way back to the DB.
lastNameLabel
lastName < name of the text field
I can certainly appreciate localizing the front end of an application and I'm not saying not to use labels . All I'm saying is the server code shouldn't have any knowledge of it.
Admin
You name it "crap" and go back to your BA or Web Designer and find out if they know anything about usability.
Admin
Wonderful. Great contribution to the discussion.
As I suspected, you just blindly follow the dogma...don't let the real world intrude on "The Right Way".
Admin
It's difficult for me to envision a circumstance where the same information would be duplicated like this. I would probably need more context to solve the problem.
To give you a scenario which may be completely inappropriate:
Let's say we're creating an NPC (non-player character) editor for a game, and we have a drop down list of available last names for a particular region to which the NPC belongs. This list is subject to change, however, so you wouldn't want to use that same list to display existing last names: You might receive errors stating that the selected value was not contained in the list.
In that case I'd have a text box for 'lastName' which represents the current NPC last name. The last name list is only used for assigning new last names, so I would name it 'newLastName'.
My example is indeed contrived, but it's the only consolation I can give outside of a request for more context.
Admin
ditto - 'crap' must be here soley for the entertainment value
Admin
I don't know what to tell you that hasn't already been said. You can do whatever you want on the client to make your life easier. Just don't force other layers of the application to comply with it by naming form elements after their GUI representation. Someone said it earlier...should we take these variables names all the way back to the data layer? I can see it now. We can have a table named TBL_EMPLOYEE with fields NUM12_EMPLOYEE_ID, VCHAR20_FIRST_NAME, VCHAR20_LAST_NAME, VCHAR10_DEPT_ID, DTIME_CREATED, DTIME_UPDATED. Or, here is a great idea...let's limit UI related names to the UI?
Admin
I would use lbl and txt prefixes. If I'm using an IDE with code completion, the prefixes can help me get the right variable name faster, and if I'm not, I still need something to tell them apart.
One solution is to name them like this: lastName, lblLastName. This way the (apparently grumpy) server guys will never know about my deviant naming conventions.
As long as the submitted name-value pairs are named based on the form element names, there will be a problem here. Either the presentation layer has to keep type information out of the form element names, or the server-side is going to end up knowing something about the presentation. A fair number of people here (myself) included like to name ui stuff with prefixes, and a fair number of people here would be seriously offended if their server-side code had crap like $_POST['txtFoo'] in it.
IMO, the server side can live with it, and certainly doesn't need to post flames and fantasize about firing anyone who'd use a prefix. But the stuff I write, I'd probably write the client-side and server-side code, so what the heck do I know about big systems?
Admin
If we're talking the layers underneath the UI, then I fully agree. But to access a control's value for any server-side action in ASP.Net, typically you'll ask the control itself.
Admin
What the hell kind of slippery-slope argument is that?
If the column names had to be named the same as the form controls, that would be a good reason to keep naming conventions out of your form. In that case the burden on the UI programmer is less than the burden of dealing with stupid column names.
But someone, somewhere, takes form data and puts it in the database. Asking that guy to not explode in a ball of rage when passed 'txtLastName' is a bit different than naming your columns after ui controls.
Admin
Here's a hint. If you're going to ask for my reasoning why I believe you said something, don't assume that I don't have reasoning and insult me by telling me to read carefully.
Now - if you can behave like a civilized adult and not a crying child, we can continue.
You stated, " 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."
Let's analyze, shall we? You say that a real programmer doesn't "cry" about what the other guy is doing. This statement clearly makes no mention of times when it would be appropriate to shed a few tears and suggest a change to a process. You simply state that at no time should a real programmer raise any concerns about anything else that another person is doing.
From that statement I was able to make the magical leap into saying you are advocating a hide your head in the sand approach. Just ignore any problems on the horizon and go about your business, right?
As a manager of programmers, it becomes apparent who is being proactive when it comes to creating good software and who is just trying to get what they need to do done. I want people under me who are thinking about the big picture - not those who won't "cry out" when they see a problem. [And I wouldn't even say that crying out has to bring about a change, it's good for people to just discuss processes that they may not fully understand and question why something is done a particular way. Your advocation of just dealing with whatever exists suggests to me that you are not a person who gives too much concern to the overall picture. You may be very good at getting your particular piece of the puzzle to fit but I can only conclude that you don't add much value beyond that. So, again, I'd fire you. Especially since you appear to be a jerk too.
God forbid people have a discussion about best practices.
Sorry Jeff, we can't all be like you and just accept the way things are done as unchanging.
Get a spine Jeff, it'll help you.
Admin
Well said Mr. President
Admin
You don't name a label, it's retarded. You use the field's ID to fill the label's "for" attribute and that's all, the "name" attribute is only valid for form fields that get posted to the server.
So you name your textbox "lastname", you ID your textbox "lastname" and you put "lastname" in your label's "for" attribute (you may change the case to fit your tastes), that's all there is to it.
Now if I ever needed to name a label (for styling purposes, or server OO generation rules), i'd probably use fieldname+"Label", it's the most semantically meaningful choice
You wonder who the heck came up with such a monstruosity having two semantically identical informations in two different controls and you kill him with fire.
Now for this precise case, i'd probably pick "lastNameSuggestion" and "lastNameInput", because the first means that it's a last name you suggested and the other one that it was a "free entry", these are meaningful and self sufficient names.
And they actually tell you the (semantical) sense of the control, it's role in the application, not that it's a fucking select box which no one cares about.
Admin
hmmmm... some of your quotes to me : "get a spine" ... saying I "hide my head in the sand" .... telling me to "be a 'man'" .. calling me a "jerk" .... and so on ...
And you feel that I insulted you by requesting that you read all my posts carefully??? Which, unfortunately, you sitll haven't done .... Interesting ...
I don't want to insult you further by suggesting that you go back and actually read what I've written (all of it, in all my posts in this thread, and not just snippets), so I won't, which means that I guess our discussion must end here. I do hope (and I mean this in all sincerity, not as an insult) that you handle the management of your programming team with better communication, patience, comprehension to details, and understanding than you have demonstrated here.
Admin
I'm sorry, but that's just ridiculous.
Obviously, there is (at least one) abstraction layer between the web server and the DB.
We're having this discussion because there is no such layer between the HTML element and its server-side representation; it is the same thing, so it must be named appropriately, hopefully satisfying the semantics of both the UI and the server. Sheesh, you're obtuse.
Admin
You need to chill out the buddy. I mean look at your avatar you look like some mad dog.....
Lets say I haven't worked on my app (WEB APP) in 3 years and I have to make some validation changes because someone finally found that validation flaw I didn't catch. I open my god awful php, or jsp code or even better perl, up and I find the spot where the glitch is it named Address I assume it's a textbox because I don't remember and let's say I don't have access to all the code for somereason.
OH! BLING BLING! That was a Drop down list and I treated it like a textbox now that entire page is broken and my long time client fires me for being an edit. Not very likely but I have seen things like that happen.
That's why I love ASP.Net it stomps all over every other weak ass spliced n hacked glue language out there.
Yes I validate my data in js and in codebehind... you know how reliable js is ...
Admin
>>Is it HTML that requires you to prefix a f-in text box with "txt" or "sel"? Is that how it works?
hnmm ... I don't remember saying that. or advocating it ... hmm, I might have even said that I even agree with you about the benefits of, in general, NOT doing it .... It's right there, you quoted it yourself ...
Admin
Admin
Guess what, Einstein? In ASP.Net, the Id is used as the basis for the client-side and server-side identifier. Now follow along closely and you might learn something.
I said it was contrived, for discussion purposes. Get over it.
Fair enough, but that's not always easy to derive.
Well, the UI developer cares about it, and she would like a meaningful name. This is especially handy if a function expects a certain type (javascript being loosely typed).
Admin
Hum... I thought this was for the benefit of the developer, and for the sake of consistency. I wasn't aware that code written in C#, Java, Delphi, or VB or any other language had any "interest" in the variable types either... So why do people prefix variables in those languages?
-dZ.
Admin
You don't know Paula very well. The alert box would say "Form1 = Brillant!"
dZ.