- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- 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
I'm not 100% sure, but if the parent control is an INamingContainer, then FindControl could return a different control. (Yes, they do a cast to Panel, but it's trivial to create a control which inherits from Panel and implements INamingControl.)
Oh and BTW, why do they cast to Panel? FindControl is defined on Control (the base class), not Panel.
Also, if the control's ID is modified, say, to "rdoSmokeYesHeavy", the event handler method doesn't get automatically renamed; so it's entirely possible FindControl returns null in this case.
Admin
TRWTF is that they did cast the sender to a
RadioButton
. That would be enough. But then did some nonsense logic to get the containingPanel
and have it find that same radio button.Admin
The parents caught the kids smoking, then punished them by having them update this code for work.
Admin
Cruel and unusual punishment if ever I saw it.
Admin
btnRandom.Clicked += rdoSmokeYes_CheckedChanged,,,,,
Now the code has meaning... They registered the handler on the WRONG control, but it is a sibling of the control with the logic...
Admin
Having to preface your radio buttons' names with rdo, buttons with btn, etc, is a dead giveaway of poor coding.
Admin
I can see this copied from a WinForms application where GenerateMember was habitually set to false.
Admin
I've seen similar things in JavaScript.
onclick=myFunc(this.id)
in the HTML element, thenYou could just use
myFunc(this)
and skip the search in the function.Admin
When WebForms was originally a thing this kind of Hungarian notation was not only common, it was all over Microsoft’s examples and descends from the original Visual Basic when the IDEs were less sophisticated than they were today.
So that’s not necessarily an indicator of poor code in this context.
That said, even in the early 2000s when I was working in WebForms it just all felt…wrong. Very wrong. I’ve turned down jobs that would require maintaining this, but the joke’s on me because now I have to work with Angular code that’s just as bad.
Admin
Could this be defense against being called from the wrong place?
Admin
Quite the contrary. When working with any sort of UI component it's actually pretty common and a good idea to use Hungarian prefixes like that because they allow you to keep sensible names for both controls and backing fields.
For example say you have a form that requires the user to enter his Name along with a bunch of other information. And for each of those you want a label with a description of the entry field (localizable), a text input, a label for error messages (if any) (localizable), a validation function, a processing function and a backing field for saving into the database.
The standard way to name them is to call them all after the item you are working on and just use prefixes. So for Name you would have: lblName = label in which you put the "Name". (localizable) tbName = input text box for name. lblNameError = label in which you print errors for name entries. (localizable) ValidateName(name) = the validation function. ReadName() = the processing function that reads the name from the text box, checks validation and if valid saves it to the backing field. Name = the backing field in your form that you put the value of the text box in after clicking save.
And than the same for last name, password, phone number etc. Each of them having the same structure just with Name replaced for what ever other thing it's referring to. The end result is a form where the names them self form a structure that's easy to understand and maintain at a glance because it's so formulaic.
Admin
Are you more likely to want to see all the labels, or all the elements relating to Name? I would expect that maintainers would find the latter more useful, in which case a suffix would be more useful than a prefix: NameLabel, NameControl, NameBox.
Which then makes it more obvious that you should be using a framework that let's you encapsulate that stuff.