Main Board > Programming

Strange if then else behavior

<< < (2/3) > >>

Mike King:
Add a comma after the label to start the list from there.  Without a trailing comma you will only get one line.

Mike Hatfield:
Ok, got it.
Is this what I should see? The listing includes the internal generated line numbers so that you can edit at the command prompt ?
:
-}list edit set_userid,
0071 Set_userid:
:
0072       IF NOT(%inomads'ForceLogon) AND %inomads'LogonReqd$<>"Y
:           THEN LET %inomads'Userid$=NID;
:                RETURN
0075 !
0076       DEF UID="*Void*" LOCAL
0077       CALL "*secure","F:LOGIN"
0078       DEF UID="*"
0079 !
0080       IF %inomads'Userid$=""
:           THEN EXITTO SKIP_TX
0082 !
0083       IF %inomads'use_signon_uid
:           THEN GOSUB Linux_signon WITH reqd_uid$=%inomads'Userid
0085 !
0086       RETURN
0087 !
0088 start_trace:
:
0089       LET x$=PTH("*plus/inomads/tracefiles",ERR=*RETURN)
0090 !
Press <ENTER> to continue or <F4> to exit:

Thomas Bock:
Mike

You wrote

--- Quote ---The issue is a result of the line oriented nature of the language.  IF ... THEN ... ELSE ... will basically process what is on the line.
--- End quote ---

This rises the question how does PxPlus find the closing curly braket? Are there any performance aspects?
As I don't like premature RETURNs or EXITs my coding style looks like this.

--- Code: ---SUB_ROUTINE:
if condition {
txt$  = "Are "
txt$ += "these "
txt$ += "lines "
txt$ += "processed "
txt$ += "in "
txt$ += "some "
txt$ += "way "
txt$ += "during "
txt$ += "execution "
txt$ += "in "
txt$ += "order "
txt$ += "to "
txt$ += "find "
txt$ += "the "
txt$ += "closing "
txt$ += "curly "
txt$ += "bracket?"
print txt$
}
return
--- End code ---
Would that routine be faster using a premature RETURN?

Mike King:
Mike,

Yes the line numbers are assigned so you can edit at command mode if needed when running in text mode.  Mind you with PxPlus 2023 due in May you should be able to run EZWeb on a Linux/MacOS/AIX box then use ED+ to edit your programs graphically from any browser.

Thomas,

When looking for the closing bracket the system has to scan ahead through the code, this is due to the interpretative nature of the language and that you can alter code at run time.  Given this, from a performance perspective it is better to keep the directives on one line as scanning will be faster. 

Also, as mentioned earlier, I generally prefer moving multiple lines to smaller subroutines.  A GOSUB takes very little time and will often run faster than scanning looking for brackets.  I also find it has the advantage that if I need to insert additional lines into an IF condition having them in a subroutine makes that easier especially when they are sub-ordinate IF directives. I find it also helpful if the subroutine name provides a 'clue' as to what the logic is doing.

For Example:

    IF QtyOnHand <= 0
      GOSUB BackOrder
    ELSE
      GOSUB CommitInventory

I have seen far too many programs not work because someone inserted or changed a few lines of code in between curly brackets that they didn't realize were present.  By avoiding curly brackets and using *IT or ED+ to format your code I find it makes it more readable and supportable.  I almost never use curly brackets (but maybe I'm just a bit weird in that respect).

Peter.Higgins:
Mike,
Thanks Mike.  Your comments on the Curly braces and forward scanning are very helpful.  I've found the UltraEdit text editor really helps when set for Pvx code to match braces.  Now I know to also reduce lines.   I use the GOSUB method often for simplifying the decision logic which can reduce lines processed by listing IF decisions lines in declining frequency and putting a return at the end of each.

Navigation

[0] Message Index

[#] Next page

[*] Previous page