And on a related note {more geekery}
Oct. 13th, 2006 03:47 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
If you program, please only use code to toggle things back and forth when you're absolutely certain that you want something to be the opposite of what it was. For example (completely hypothetical, of course) say you have graphical image that you sometimes want to display and sometimes want to hide. Let's also say you have a toggle function which will hide it if it is showing and show it if it is hiding.
That's all well and good, but there is only one type of situation in which I can think that would be appropriate, and that would be the situation where you can say "At this point I don't care what it was before, but I want it to be the other way now!"
Never assume that you already know what state it is in unless you just checked it, but if you're doing something like "if it is visible, then toggle it" when you want to hide it you should probably two different chunks of functionality designed specifically to hide it or show it in those situations where you know you want it definitely to be turned on or definitely to be turned off.
Yes, it is possible to use just the toggle function and get the results you want, but it requires extremely rigorous analysis of the rest of the program to be certain that it will never accidentally end up turning it off when it was supposed to be turned on (and even then, you probably can't be 100% sure that it will work every time--what if there was some incredibly obscure state that you didn't think of but which could, under just the right circumstances, occur?)
But possible and easy, efficient, and least-stressful are not always the same thing. If you want it hidden, don't call the toggle function and hope that it was visible (or do the extra work of checking whether to see that it's visible and then call the toggle function) or just call the hide function. Setting it to hidden twice won't make it more hidden (at least not if it's a binary state thing, which it should be if you're thinking about using a toggle in the first place), but it will guarantee that it is exactly where you want it.
Take control of your program. Don't be subject to its fickle nature. Put it in its place!
We now return you to your irregularly scheduled WootOff
That's all well and good, but there is only one type of situation in which I can think that would be appropriate, and that would be the situation where you can say "At this point I don't care what it was before, but I want it to be the other way now!"
Never assume that you already know what state it is in unless you just checked it, but if you're doing something like "if it is visible, then toggle it" when you want to hide it you should probably two different chunks of functionality designed specifically to hide it or show it in those situations where you know you want it definitely to be turned on or definitely to be turned off.
Yes, it is possible to use just the toggle function and get the results you want, but it requires extremely rigorous analysis of the rest of the program to be certain that it will never accidentally end up turning it off when it was supposed to be turned on (and even then, you probably can't be 100% sure that it will work every time--what if there was some incredibly obscure state that you didn't think of but which could, under just the right circumstances, occur?)
But possible and easy, efficient, and least-stressful are not always the same thing. If you want it hidden, don't call the toggle function and hope that it was visible (or do the extra work of checking whether to see that it's visible and then call the toggle function) or just call the hide function. Setting it to hidden twice won't make it more hidden (at least not if it's a binary state thing, which it should be if you're thinking about using a toggle in the first place), but it will guarantee that it is exactly where you want it.
Take control of your program. Don't be subject to its fickle nature. Put it in its place!
We now return you to your irregularly scheduled WootOff
no subject
Date: 2006-10-14 12:13 am (UTC)Sounds like an interesting back story to that little code lesson. ::grin::
no subject
Date: 2006-10-16 12:01 pm (UTC)The best place I can think of where you wouldn't bother checking the state before deciding whether to toggle is if it's somehow related to a control that a user can manipulate to turn something on or off, which implies that they've already checked the state and determined that it should be the opposite of what it currently is (you can only protect users from themselves to a certain point, after which they have to take responsibility for their actions ;) That's really the only place that I can think of off the top of my head where I'd use a toggle function. That, or maybe in a loop that has something that should switch states each pass through.
But yeah, the short back-story is mostly covered in the previous entry about ripping out old code and trying to make it work. There's one point at which it loads several images from a webserver. When it starts loading, it displays (using a toggle function) a banner notifying the user that the images are loading. When a certain image from the set finishes loading, the banner is again toggled (regardless of whether that was actually the last image being loaded, but that's a topic for a different coding lesson ;) The problem is that the user can do the same operation to load more images while the old images are still loading (i.e. while the banner is still showing). The beginning toggle is called, but this time since the banner was already displayed it gets hidden. The images load, including the magic one that toggles the banner, which causes it to display again. After that it stays on even though the images finish loading shortly after that, and the users get confused as to why it's taking so long because the banner hasn't disappeared yet.
While I haven't fixed everything yet, I did change it so now when the magic image loads it hides the banner instead of toggling it. Not as good as I'd like it to be, but at least it's getting closer ;)