Date: Fri, 20 Dec 2024 16:27:28 +0200
On Fri, 20 Dec 2024 at 16:17, Jan Schultke <janschultke_at_[hidden]> wrote:
>
> > It's very much a technical problem, and not a personal preference, ...
>
> Let's put it like this: If we are solving a technical problem, then do
> the sets of labels NEED to be separated, strictly speaking, from a
> technical viewpoint? If yes, what technical issue does it resolve?
>From a purely technical viewpoint, an unstructured jump construct like
goto has the potential to significantly increase
the cyclomatic complexity of the code. By making such unstructured
jumps not eligible for jumping to loop-names,
that cyclomatic complexity increase is just categorically turned off.
See, the 'dislike' for goto isn't a 'dislike' at all. It has nothing
to do with what anyone likes or dislikes, it's all about
that cyclomatic complexity, and the consequences thereof, consequences
in analyzability (whether done by a machine
or done by wetware reasoning), consequences in maintainability,
consequences in implementability in compilers' constant
expression evaluators, and more.
>
> > It's very much a technical problem, and not a personal preference, ...
>
> Let's put it like this: If we are solving a technical problem, then do
> the sets of labels NEED to be separated, strictly speaking, from a
> technical viewpoint? If yes, what technical issue does it resolve?
>From a purely technical viewpoint, an unstructured jump construct like
goto has the potential to significantly increase
the cyclomatic complexity of the code. By making such unstructured
jumps not eligible for jumping to loop-names,
that cyclomatic complexity increase is just categorically turned off.
See, the 'dislike' for goto isn't a 'dislike' at all. It has nothing
to do with what anyone likes or dislikes, it's all about
that cyclomatic complexity, and the consequences thereof, consequences
in analyzability (whether done by a machine
or done by wetware reasoning), consequences in maintainability,
consequences in implementability in compilers' constant
expression evaluators, and more.
Received on 2024-12-20 14:27:41