3 ms·

There's an argument (and I think a good one) that in structured programming there should be only one return per function. It's not that hard -- you just have a

There's an argument (and I think a good one) that in structured programming there should be only one return per function. It's not that hard -- you just have a variable and you set it to what you want to return and the last line of the function returns that variable. I think that some things Wirth did with Oberon, particularly in the post Oberon-OS versions like Oberon-07, are a bit restrictive, but they are always in the service of making code easier to read, even if it makes it slightly harder to write.

cyberax 6mo ago
The problem is that pure structured programming just sucks. It doesn't have a good answers for cleanups or error handling. Structured programming was the answer to the earlier mess with unstructured gotos, but in the process of trying to improve it, structured programming became just as messy when taken dogmatically. In real life, what matters is the mental load. Every ambient condition that you need to track adds mental load. Early returns/breaks/continues reduce it while in a "structured program" you have to keep track of them until the end of the function. > It's not that hard -- you just have a variable and you set it to what you want to return and the last line of the function returns that variable. And also have a flag "skip to return" to skip all the conditions. Or you end up mutating arguments of the function. I know, I suffered through programming on Standard Pascal.
- Rochus 6mo ago
  It all boils down to the fact that ideas should be viewed as tools rather than dogmas, and famous people are neither infallible nor prophets simply because they had a few good ideas.
- rbanffy 6mo ago
  > Every ambient condition that you need to track adds mental load Thus it's wise to limit the complexity of your code. If it starts getting difficult, it might be time to break it down in smaller, more understandable, pieces.
  - cyberax 6mo ago
    "Limit" how? I suggest looking at any real code in Oberon that has to deal with the real world. E.g. a USB driver.
imtringued 6mo ago
This unnecessarily creates the need for mutable variables in every function when in practical code bases 95%+ of variables programmers define are immutable and are only mutable because the programming language forces mutability by default. Mutable variables make local reasoning harder since you have to inspect all write locations to understand the impact of any given line of code.

cyberax 6mo ago

The problem is that pure structured programming just sucks. It doesn't have a good answers for cleanups or error handling. Structured programming was the answer to the earlier mess with unstructured gotos, but in the process of trying to improve it, structured programming became just as messy when taken dogmatically. In real life, what matters is the mental load. Every ambient condition that you need to track adds mental load. Early returns/breaks/continues reduce it while in a "structured program" you have to keep track of them until the end of the function. > It's not that hard -- you just have a variable and you set it to what you want to return and the last line of the function returns that variable. And also have a flag "skip to return" to skip all the conditions. Or you end up mutating arguments of the function. I know, I suffered through programming on Standard Pascal.

Rochus 6mo ago
It all boils down to the fact that ideas should be viewed as tools rather than dogmas, and famous people are neither infallible nor prophets simply because they had a few good ideas.
rbanffy 6mo ago
> Every ambient condition that you need to track adds mental load Thus it's wise to limit the complexity of your code. If it starts getting difficult, it might be time to break it down in smaller, more understandable, pieces.
- cyberax 6mo ago
  "Limit" how? I suggest looking at any real code in Oberon that has to deal with the real world. E.g. a USB driver.

imtringued 6mo ago

This unnecessarily creates the need for mutable variables in every function when in practical code bases 95%+ of variables programmers define are immutable and are only mutable because the programming language forces mutability by default. Mutable variables make local reasoning harder since you have to inspect all write locations to understand the impact of any given line of code.