- 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
if (((PVCheckBox)sender).Checked) { frist_ = true; }
Admin
Google Closure (RIP) suggested a trailing underscore for private variables: https://google.github.io/styleguide/jsguide.html#naming-method-names This was what we used till we finally got rid of it.
Admin
Why are they casting to CheckBox? I doubt that PVCheckBox is a supertype, so this doesn't make any sense.
Admin
My guess is that
PVCheckBoxextendsCheckBoxand the cast is superfluous.Admin
So the requirement is: There are two check-boxes, and one or both must be checked. I'm not saying that requirement is wrong, but it's sufficiently unusual that I would want it confirmed.
Also, using check-boxes for this requirement is horrible UI. Better to have radio buttons with Option One / Option Two / Both.
Admin
sender is still of type object, so it must be cast to something that has a Checked property. The fact that they cast it to PVCheckBox in one place and CheckBox in another is probably just inconsistency. I certainly hope that the PVCheckBox interface doesn't have it's own Checked property that shadows CheckBox's Checked property.
Admin
Guess: This was originally a checkbox. Now it should be a radio but somebody demanded that the original be left alone.
Admin
Assuming there are only two check boxes, they just need onechecked_ = CheckBox_func.Checked || CheckBox_member.Checked.
If there are other check boxes that may trigger this code, that's... a bigger WTF that doesn't, or at least shouldn't, make any sense.
Not sure I have any problem with two checkboxes instead of radio buttons. Especially if a third option might be added later, and possibly then a fourth. You want 16 buttons to cover all possible combinations of four options?
Admin
I think there's a bit of confusion going on in this article with mixing up snake case with Hungarian. All those examples are in fact not Hungarian at all, they are just using snake case.
Now compared to other languages, .net had naming conventions from the very start which are actually pretty simple:
Now the last part never got a huge amount of love and was shorten to a simple '_'. Obviously there would be a naming conflict when local variables have the same naming convention as do have field members, so in a good naming scheme they are different (in a verbose one you need an additional keyword, like this which is an option but bad practice).
Obviously there's a number of times where those naming conventions were broken, famously in WinForms by MS themselves on launch for event handlers (snake case separated PascalCase). These days it's pretty common to do this for unit tests.
And there we go, a quick tutorial how to name things in .net since it launched; would have MS decided on the underscore without the completely redundant static prefix then .net would have been the only language I know with a clear naming convention from the very start.
Addendum 2024-01-05 04:25: BTW the example is an even handler, and it was used with a field instead of a property (as is generally considered best practice - that's a whole other topic). Additionally the private field is using snake_case for some reason and this results in this weird naming mishmash of awfulness.
Admin
Even handlers always have their sender defined as object (it's an old outdated .net1 idea), so you have to upcast the sender to the appropriate type. Since CheckBox is standard WinForm control, I'm pretty sure that PVCheckBox is just a derived type which is pretty common in those old days when inheritance was heavily used over composition in those old presentation layers.
Admin
I think I speak for everyone here when I say we'd just as soon not hear about your private member.