How to understand GoTo's document note？

[gurj]

How to understand GoTo's document note ？

in pb's doc:
Note: To exit a loop safely, you always must use Break instead of Goto, and never use it inside a Select/EndSelect block (Unless you have the ability to manage the stack yourself, correctly.)

If i use Goto to the outside of a loop,
And then determine,
Use Goto again to enter this loop, Does this meet the safety instructions?

code:

Code: Select all

Repeat
 test=Random(2)
 If test=1
  
  n+1
  If n>4
   Break
  Else
   Goto re1
  EndIf
  
 Else
  Select test
   Case 0
    Continue
   Case 2
    Continue
  EndSelect
  
 EndIf
 re:
ForEver

End
re1:
Goto re

[Kurzer]

no, because your goto re1 is still executed inside the loop. jumping out of the loop without break will lead to an invalid stackpointer.

between the repeat and the forever you must not use a goto command. your if conditions doest have any effect to this rule.

Sent via mobile phone

[Josh]

I'm not an expert, but I think it's ok if you jump back again and you don't use outside commands that affect the stack.

In general, I would say don't do it. It's not a clean programming style and you will just have problems with such constructs.

[gurj]

Thank you to the two gentlemen for their answers!

[gurj]

It's too easy to construct loops with Goto:

Code: Select all

re0:;Repeat
 test=Random(2)
 If test=1
  
  n+1
  If n>4
   Goto ree
  Else
   Goto re1
  EndIf
  
 Else
  Select test
   Case 0
    ;...
   Case 2
    ;...
  EndSelect
  
 EndIf
 re:
Goto re0;ForEver
ree:
End
re1:
Goto re

[infratec]

Very simple rule:

Don't use Goto and Gosub

This relicts are from an earlier time of programming.
They should be avoided and maybe should use compiler warnings to make this clear.

I, personally, also avoid several ProcedureReturns in one procedure.

[Josh]

Very simple rule:

Don't use Goto and Gosub

This relicts are from an earlier time of programming.
They should be avoided and maybe should use compiler warnings to make this clear.

Which is your opinion, though. For Goto the same applies as with programming in general. You should know what you are doing, otherwise it will cause problems. If you know how to use Goto, there are no problems.

[Little John]

Which is your opinion, though. For Goto the same applies as with programming in general. You should know what you are doing, otherwise it will cause problems. If you know how to use Goto, there are no problems.

That's true on principle. The problematic part of your last sentence is the If, though.

After having read code here on the forum for 10+ years, it seems to me that Dijkstra's observation is still correct:

Since a number of years I am familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce.

[luis]

Very simple rule:
Don't use Goto and Gosub
This relicts are from an earlier time of programming.

If you program in another language you can almost always avoid them.
In PB, like in plain old C, they are a very useful thing to have.

viewtopic.php?p=374524#p374524
viewtopic.php?p=330250#p330250
viewtopic.php?p=415897#p415897

They should be avoided and maybe should use compiler warnings to make this clear.

That would be really a ridiculous thing.
I use gotos when they can simplify my code and make it more clear and better maintainable, and certainly I don't want to have to read useless and distracting warnings about a problem which does not exists every time I compile a program.

About warnings in general, the compiler should have at least a compiler directive to selectively suppress warnings by their number (at minimum), and ideally also globally in the compiler options.

Else warnings should simply not be implemented.

[Mijikai]

I just use inline assembly to jump around...

Code: Select all

!jmp next
;...
!next:

[gurj]

thanks all.
thanks luis for lnk.

[GedB]

Very simple rule:

Don't use Goto and Gosub

These relics are from an earlier time of programming.
They should be avoided and maybe should use compiler warnings to make this clear.

I, personally, also avoid several ProcedureReturns in one procedure.

Obviously It's a personal opinion, but I hope you don't mind discussing this further. It's helpful for newer programmer to see discussions around the principles.

My advice to programmers: don't use goto until you understand how the stack works. You should learn how the stack works.

I'm a strong advocate of using multiple returns in one procedure when it makes the flow of the code cleaner and clearer.

I consider the Single Entry Single Exit principle another relic from an earlier time. We can depend upon PB to clean up after us, so why waste time adding additional variables or flags?

For example, the common idiom in PureBasic is to wrap the use of resources in an If Statement, like this example from the File documentation:

Code: Select all

If CreateFile(0, "PureBasicTestFile.txt")
  WriteStringN(0, "         This is a PureBasic file test")
  WriteString(0, "Now it's on ")
  WriteString(0, "the same line.")

  CloseFile(0)
Else
  MessageRequester("PureBasic", "Error: can't write the file", 0)
  End
EndIf

Personally I don't like this approach. What if I want to open two files and then a window to display the results. You end up with a pyramid of doom:

Code: Select all

If ... Create File 1 ...
  If ... Create File 2 ...
     If --- Open Window ...
        ... Lots of code ...
     Else
        ... Error ...
     EndIf
     Close File 2
  Else
     ... Error ...
  EndIf    . 
  Close File 1
Else
   ... Error ...
EndIf

Procedure Return

The Error handler is miles away from the condition, and there's a risk that I'll add code somewhere I shouldn't. For example, some wrap up code after the window closes. It's easy to forget the right place to put resource clean up.

Refactoring in particular becomes difficult, because of the need to untangle the code and it's preconditions.

I much prefer to use precondition gates like this:

If Not CreateFile...
... Error ...
ProcedureReturn
EndIf

If Not CreateFile...
... Error, close file 1 ...
ProcedureReturn
EndIf

If Not OpenWindow...
....Error, close file 2 ...
ProcedureReturn
EndIf

... Lots of code ...
... I want to avoid ProcedureReturns here because I don't want to repeat the clean up. Sometimes I might use a Goto to jump to that clean up. ...


... The clean up. Closing files, etc. ...

ProcedureReturn

The precondition gates sit at the top and it's clear what is happening. By the time I get to my main body of code I know that everything has gone well. When I'm refactoring the methods preconditions are separated and easy to move.

It's a matter of personal taste. I value writing code that is clean and clear, even if it means using constructs that are considered harmful.

Here are some more discussions on the topic:

• https://softwareengineering.stackexchan ... -come-from
• https://www.quora.com/What-are-the-disa ... rogramming
• https://stackoverflow.com/questions/483 ... exit-point

Regards,


Ged

[GedB]

Very simple rule:

Don't use Goto and Gosub

These relics are from an earlier time of programming.
They should be avoided and maybe should use compiler warnings to make this clear.

I, personally, also avoid several ProcedureReturns in one procedure.

Obviously It's a personal opinion, but I hope you don't mind discussing this further. It's helpful for newer programmer to see discussions around the principles.

My advice to programmers: don't use goto until you understand how the stack works. You should learn how the stack works.

I'm a strong advocate of using multiple returns in one procedure when it makes the flow of the code cleaner and clearer.

I consider the Single Entry Single Exit principle another relic from an earlier time. We can depend upon PB to clean up after us, so why waste time adding additional variables or flags?

For example, the common idiom in PureBasic is to wrap the use of resources in an If Statement, like this example from the File documentation:

Code: Select all

If CreateFile(0, "PureBasicTestFile.txt")
  WriteStringN(0, "         This is a PureBasic file test")
  WriteString(0, "Now it's on ")
  WriteString(0, "the same line.")

  CloseFile(0)
Else
  MessageRequester("PureBasic", "Error: can't write the file", 0)
  End
EndIf

Personally I don't like this approach. What if I want to open two files and then a window to display the results. You end up with a pyramid of doom:

Code: Select all

If ... Create File 1 ...
  If ... Create File 2 ...
     If --- Open Window ...
        ... Lots of code ...
     Else
        ... Error ...
     EndIf
     Close File 2
  Else
     ... Error ...
  EndIf    . 
  Close File 1
Else
   ... Error ...
EndIf

Procedure Return

The Error handler is miles away from the condition, and there's a risk that I'll add code somewhere I shouldn't. For example, some wrap up code after the window closes. It's easy to forget the right place to put resource clean up.

Refactoring in particular becomes difficult, because of the need to untangle the code and it's preconditions.

I much prefer to use precondition gates like this:

Code: Select all

If Not Create File 1...
  ... Error ...
  ProcedureReturn
EndIf

If Not Create File 2...
  ... Error,  close file 1 ...
  ProcedureReturn
EndIf

If Not Open Window...
   ....Error, close file 2 ...
  ProcedureReturn
EndIf

... Lots of code ...
... I want to avoid ProcedureReturns here because I don't want to repeat the clean up.  Sometimes I might use a Goto to jump to that clean up. ...


... The clean up.  Closing files, etc. ...

ProcedureReturn

The precondition gates sit at the top and it's clear what is happening. By the time I get to my main body of code I know that everything has gone well. When I'm refactoring the methods preconditions are separated and easy to move.

It's a matter of personal taste. I value writing code that is clean and clear, even if it means using constructs that are considered harmful.

Here are some more discussions on the topic:

• https://softwareengineering.stackexchan ... -come-from
• https://www.quora.com/What-are-the-disa ... rogramming
• https://stackoverflow.com/questions/483 ... exit-point

Regards,


Ged

[Kurzer]

GedB,

in principle, I fully agree with you. This is also my approach in procedures (insert several small checks without creating a nested If/Endif desert)
But exactly the example you've shown is a good example of when you can use a Goto effectively. It's not a loop, so there won't be any stack problems.

Let's say we keep the files open all the time, Then in your example you have to write the clean up code up to 4 times, e.g. Closefile1. This is an ineffective method. If you have to change something in the clean up code, you have to change all these independent codes.

Code: Select all

If Not CreateFile1...
... Error ...
ProcedureReturn
EndIf

If Not CreateFile2...
... Error, close file 1 ...
ProcedureReturn
EndIf

If Not CreateImage1...
... Error, close file 1, close file 2 ...
ProcedureReturn
EndIf


If Not OpenWindow...
....Error, close file 1, close file 2, FreeImage1 ...
ProcedureReturn
EndIf

... Lots of code ...
... I want to avoid ProcedureReturns here because I don't want to repeat the clean up. Sometimes I might use a Goto to jump to that clean up. ...


... The clean up. Closing files, etc. ...

ProcedureReturn

I do indeed prefer a Goto in these cases and have only one clean up code in the whole procedure, which is used both for the case of an error and for successfully completing the procedure.

Code: Select all

If Not CreateFile1...
... Error ...
Goto Error
EndIf

If Not CreateFile2...
... Error
Goto ErrorCloseFile1
EndIf

If Not CreateImage1...
... Error
Goto ErrorCloseFile2
EndIf

If Not OpenWindow...
....Error
Goto ErrorCloseImage1
EndIf

... Lots of code ...

CloseWindow

... The following clean up code is the same clean up code in case of an error

ErrorCloseImage1:
CloseImage 1

ErrorCloseFile2:
CloseFile 2

ErrorCloseFile1:
CloseFile 1

Error:
ProcedureReturn

Kind regards,
Kurzer

Edit 24 Apr. 2019: Corrected some typos and parts my code example, because there were useless ProcedureReturn's (copy/paste error)

[gurj]

why do i currently use Goto ?
see:
pb-event-fast:
viewtopic.php?f=12&t=72700