Main Board > Programming

Strange if then else behavior

(1/3) > >>

michaelgreer:
This is an abstraction of a code issue we are seeing:
0005 let mike$="P"
0010 if mike$="P" then {
0015 print "Yes P"
0020  } else if mike$="T" then {
0025 print "Doing T too"
0030  }
If you execute this, you get both outputs when it seems you should not get the "Doing T too".  I realize this is not great coding (I didn't write it) but it seems it should work.

James Zukowski:
Yes, it looks like it should. If you add a brace before the second IF and close it at 35, it works fine. Evidently, if you {group statements} for the THEN, it's expected for the ELSE as well.

Mike King:
The issue is a result of the line oriented nature of the language.  IF ... THEN ... ELSE ... will basically process what is on the line.

To span multiple lines then the THEN or the ELSE *MUST* be immediately followed by the OPEN bracket otherwise the conditional processing ends.

What was happening is that when the system saw your ELSE IF MIKE$=... because the ELSE was not followed by a curly bracket the IF directive was now fully complete thus the next line was executed.

Personally I try to avoid curly brackets as they make lines hard to read.  I would enable formatted output in *IT and code the line as:

0005  mike$="P"
0010  IF mike$="P" \
        THEN PRINT "Yes P" \
        ELSE IF mike$="T" \
              THEN PRINT "Doing T too"
0020 !

Its just easier to read.

And where there are more than three lines in any of the of the IF blocks I usually put the code into a GOSUB with a label to make the code more readable.  For example in instead of just PRINT "Yes P" you had 10 lines of code to execute I'd put that in a GOSUB called something like Mike_Code_P.  (My $0.02)
 

Mike King:
Quick follow up:

To give you an idea of how my coding style looks have a look at *plus/inomads/inomads around the label Set_Userid:

If you load this program and do a standard LIST EDIT SET_USERID (or call the program up in the *it or *ed+ editors with Formatted output enabled) you will get something like this:

Set_userid:
  IF NOT(%inomads'ForceLogon) AND %inomads'LogonReqd$<>"Y" \
   THEN %inomads'Userid$=NID;
        RETURN
 !
  DEF UID="*Void*" LOCAL
  CALL "*secure","F:LOGIN"
  DEF UID="*"
 !
  IF %inomads'Userid$="" \
   THEN objsec=NEW("*secure");
        IF objsec'unsecured \
         THEN MSGBOX "System security is not enabled but required for this transaction","Error","STOP";
              EXITTO SKIP_TX \
         ELSE EXITTO SKIP_TX
 !
  IF %inomads'use_signon_uid \
   THEN GOSUB Linux_signon WITH reqd_uid$=%inomads'Userid$
 !
  RETURN

Which I find fairly easy to read and follow. 

Now some of the lines if you list them un-formatted are quite long, with edited listing enabled the built in code formatting makes following the logic quite easy -- and in my opinion much easier than coding a bunch of brackets. 

Mike Hatfield:
Hi Mike, I had no idea you could do a LIST EDIT..... from the console prompt. very handy I think.
So, I thought I'd try it on the inomads program. The IT editor is set to 'editted list' and 'disallow lines'

I get this

-}LIST EDIT SET_USERID
0071 Set_userid:
:
Am I missing a setting somewhere?
Thanks

Navigation

[0] Message Index

[#] Next page