What Brian said! Also, like many things, context matters; perhaps those variables are used elsewhere and they do need to be initialized. Even if not, 'habits' like explicitly initializing variables are often considered and taught as 'good programming practice'.
Personally I wouldn't write it quite this way but to some extent programming is an individual art form, especially in a hobby context; it's also good to remember that depending on where, when and by whom it was published the fact that it appears in a magazine doesn't necessarily mean it's good style or practice, as seen by the regular corrections in subsequent issues. If you want help fixing a problem then publish the whole program; if you need to criticize someone's style why not do it in a less condescending way. Note that that also leaves you open to the same criticism; I note that you don't show how you would do it instead ;-) I don't know whether it was that way originally or whether you introduced that typo, but the 'E1SE' instead of 'ELSE' in lines 17 and 21 will certainly cause a problem. m ----- Original Message ----- From: "Brian K. White" <[email protected]> To: <[email protected]> Sent: Saturday, January 25, 2020 10:49 AM Subject: Re: [M100] another program > Sometimes another explanation for a seemingly no-op line is, given that > it's impossible for a human to avoid forming habits, doing things by > habit, one can choose consciously to adopt habits that will more-often > work. Like always initialize your variables, or always set them to the > most likely default value before having the decision code that may > overwrite it. Rather than say, having a case statement or some if's that > are supposed to cover all cases and just trusting that one way or > another it always gets set to something valid. > > Maybe one day in Foo implementation of language X, variables are > initialized for you, so, in that case, it's not necessary. But if you > had *that* habit of by default, never bothering to initialize things > explicitly except in the exception cases where you need to or when you > manage to actually notice a problem, then you will always be running > into the problem, or worse, not realizing that you have a problem > because in testing it seemed to work. > > But if you have the habit that you always initialize, then that always > works and never hurts. > > This particular program might indeed be inelegant, but some of the > example's you're highlighting are not automatically wrong or stupid. > They might be, but the exact same line of code could also be perfectly > valid and the result of more sophistication than you rather than less. > > -- > bkw > > On 1/24/20 9:37 PM, Peter Vollan wrote: >> Oh, come now, this is spaghetti BASIC, not pointers in c. >> >> Look at this: >> >> 15 T1 = 0: T2 = 0: T3 = 0 >> 17 IF A1$ = "S" THEN T1 = 6 E1SE 21 >> 19 SC = SC + T1: IF SC = 60 THEN SC = 0: TM = TM + 1 >> 21 IF A1$ = "R" THEN T2 = 1 E1SE 25 >> 23 MI = MI + T2 >> 25 IF A1$ = "T" THEN T3 = 10: TM = TM + T3 >> 27 IF (TM + MI) > = 60 THEN TM = TM - 60: HH = HH + 1 >> >> ISTR hearing that some early computers needed their variables set to 0 >> or else they will be full of random junk. Kinkd of like an undelete >> program. But even if that is the idea, you can see that this approach >> makes no sense, as the variables are not incremented, but set to >> something else. And when I ran the program, the updated time was only >> displayed when Turns (10 minutes) was updated and I do not think that >> was meant to happen. This is what they were publishing in magazines? >> >> On Fri, 24 Jan 2020 at 13:47, Brian K. White <[email protected]> wrote: >>> Frequently when I see something that makes no sense, I discover sometime >>> later that it did actually do something. >>> >>> A line of code can look non-sensical, or merely non-optimal, because of >>> all kinds of different reasons, like it's a way to write something that >>> works on multiple platforms even though by rights they should each be >>> different, or it causes some internal effect in the interpreter or >>> hardware like loading or clearing registers as a side-effect, or it >>> pushes the internal tokenized keywords in the program around into some >>> funky byte alignment or other structure that ends up executing faster, >>> or allows some other bit of the code to do some dirty math trick with >>> pointers to addresses that by rights it should have to do some much more >>> expensive but safer way. >>> >>> Or it could actually just be dumb. Or it could be corrupted like it was >>> originally typed in wrong manually from a book or OCR'd, or it worked >>> fine on some other machine and it's only a bug now because of an >>> incomplete port. >>> >>> There is at least one program where the bugs are actually the entire >>> point of the program. The program name is, shall we say, promising. You >>> run it. It fails but the error is obvious because you are smart! So you >>> fix that clod's mistake and wonder how this crap ever made it into the >>> archives without someone else fixing it before now. It runs a tiny bit >>> further and fails again. Again the new error is obvious so you fix it. >>> Man this programmer was a freaking buffoon. You fix a couple more >>> errors, and in the end all it says is something like "wasn't that a fun >>> game?" The promise of the filename never existed. ;) >>> >>> -- >>> bkw >>> >>> On 1/24/20 2:26 PM, Peter Vollan wrote: >>>> Well, it doesn't say that. And if it did, that would still be a dumb >>>> way to do it. Then the next line sets three variables to 0 which is >>>> totally unneccessary, so that's a line that does nothing. And that is >>>> only the tip of the iceberg of the problems with this program >>>> >>>> On Thu, 23 Jan 2020 at 09:55, Dan Higdon <[email protected]> wrote: >>>>> The final number on that line should be an 11, then it works. (That is, >>>>> "ELSE 11", not "ELSE 13") >>>>> >>>>> On Sun, Jan 19, 2020 at 4:57 PM Peter Vollan <[email protected]> wrote: >>>>>> Check this out! Not only is it a dumb way to do things, but it does >>>>>> not even work the program just hangs! >>>>>> 13 IF AL$ = "S" OR AL$ = "R" OR AL$ = "T" THEN 15 ELSE 13 >>> >>> -- >>> bkw >
