A few tidbits about ifs and gotos and errors


#41

Quicktest is me an hour before travelling to a convention >_> /sidenote


#42

Yes, but usually it ends up being harder to read. Also often the computer won’t quite understand the results are analogous to an else and you’ll get things like that quicktest issue. And it’ll generally actually check whether not (var) is true even though that will be the case every time it gets there. Again, usually not a problem unless checking would crash, which is mostly only a practical consideration when you’re depending on user input (Choicescript takes care of the biggest cause of this; in many languages “a string zero characters long” and “a string that hasn’t been set” are not the same and the latter is usually trouble; sometimes it is neither equal nor not equal to any value including itself, sometimes it just crashes if you try to test equality or do much of anything)


#43

First: Thanks for posting this! It’s a good introduction and I hope it’ll clarify some things for new users, and maybe help with those frustrating “Gahhh why won’t this error go away?”


Second, and less importantly because yay personal taste, I can’t bring myself to use *if strings. I tried for most of the morning to, and I honestly can’t get used to leaving an *if without an *else to collect all those unused states even if I’m working with a finite state count. I won’t pretend I’m a particularly cautious coder, but one of the things I don’t like to leave up to chance is missing a potential state (I’m gonna blame my other coding knowledge for this one. Data processing and calculation is not good for limited finite states.)

Just for my two cents, I’ve actually really appreciated all the explanations for “when ICF would be useful” myself. It was intimidating at first (I don’t often flip switches like that, under the “if it’s set already it’s probably set that way for a reason” mindset), but it’s definitely made more sense after a few weeks re-binging the forum. I appreciate all the warnings about how it would goof up, because of course you need to know the cons, but I don’t have a problem with it being presented as an option on help threads (that’s why we all discuss publicly after all: someone posts, another person corrects with 'this will cause these problems" and after spending some time boggling at how coders get heated over a single line of code, you can eventually tease out a better understanding of how code works, and what approach works best for you)

Dear Gower, I’m sorry but I cannot hide it any more: I do love you.


#44

I admit that ICF can have its advantages, and as many have said, if you can work with it, more power to you.

Using your example with if-trees:

I’m pretty much the opposite in many cases. I know it’s not all efficient, but often I need to see the possible variable before me, at least at first, to make sure I didn’t forget anything that would otherwise slip into the else.

So, yeah, everyone their own, and to find what works best for one, one’s off best when all ways are presented.


#45

:scream: It’s prose. Which requires blank lines for new paragraphs.


#46

That’s what the

*else
   *bug

Is for. Then randomtest will tell you if you’ve forgotten. You could also use the same idea to “fix” the variable, but that’s for when it’s very important the program not crash and less important any given statement is strictly correct, because usually you won’t be 100% sure what the best value to set is. Only case you might use it for is to tell the user there’s something wrong with a text input and they need to input something else, if you’re using it in a complex enough way that just checking if it’s blank isn’t sufficent to catch all unusable ones. Every other scenario you want to find and eliminate before release.