gotoを使う想定でロジックを組むなら、それを分かりやすく図示する方法を発明してから
にしてほしい。そうじゃないとレビューする気にもなれない。
ここで出たようなgotoを使った書き直しの例なら、gotoを使ってないロジックを例えば
NSチャートとかで書いた方が、とてもとても分かりやすくて人にも説明し安いだろう。

チームメイトにロジックを説明するようにお願いてフローチャートをもってこられたら、
とりあえずバケツもって廊下に立っててくれるようにお願いしちゃうな。
システムが使われなくなるまでその人が死なずに内容も忘れずに保守するってのが保証さ
れてたとしても、仕事ではそんなロジックは受け入れ難いな。

だいたい現実的にgotoを使った方が良い場合ってのが、想定しづらい。
リソースだのコードサイズだののためのためにgotoを使うってのは、やらないと用件が
満たせないからって理由で、設計とかコーディングとかのさらに後に最適化フェーズを
設けてそこでやるんなら認めなくもないが、元からgotoを使うのが正しい場合なんての
を考慮しながらロジックを考えるような人とは一緒に仕事はできないなぁと思う。

なんでそんな書き方になってるか説明するための資料も作んないといけないし、仕事が
増えるばっかりだ。段階的抽象化とか物事を整理するとかに興味がないかできない人な
んだなとしか思えない。

誰かが事故にあってもリカバリがきくような状態を維持しようと思ったら、少しくらい
冗長になっても、なるべくわかりやすい設計＆実装にしたいって思うのは普通だと思う
んだがなぁ。