途中return問題

について書こうと思っていて、こんな（↓）ものまで用意してたのですが、

関数型言語になれてればguardやpattern matching使いたいよね！

C++とかにそんなもんないよね！

これだけでも関数内のreturn1つにしろとか言われて発狂する理由としては十分だよね！

http://d.hatena.ne.jp/uskz/20090123/p9

そういえば構造化プログラミングでの出口は１つルールは関数内にreturnが複数あるとかじゃなくてその関数の呼び出し側からみた振る舞い（戻ってくる場所が決まってる）のことだと思うんだけれど，ちゃんと勉強したことが無いので後で調べてみよう

http://d.hatena.ne.jp/uskz/20090123/p12

言いたいことを全部言われてしまいました...orz
長門さん恐るべしです。しくしく。

* * *

以下、完全な蛇足。

構造化プログラミングの目的は、可読性の向上によるプログラムの品質向上にあります。なら、心の中に描く制御構造の図に近い字面のコードを書く方が、構造化プログラミングの目的にかなっています。手段にこだわり目的を忘れるのはナンセンス。

あと、出入口一つづつルールについて、ダイクストラ先生の「構造化プログラミング論」の中では

これら流れ図は,頭で1つの入口,尻尾で1つの出口があるという性質を共通してもっています.点線で囲んだ箱が示すように,これらは,(点線の中を無視することにより,)順序的計算における単一の作用として解釈できるようになります.

（強調はわたし）

のように書かれています。カプセルを外から見たとき順序的計算の単一の作用に見えるように出来ることが目的なので、このルールについては「外から見たら」そうであればよい、と解釈して良いと思います。（ちと強引かしら(^^;）

あと、

「ステータスを変更する必要があるかどうか？」を判断しながら「遷移先のステータスを決め」ながら「ステータスを変更する」という。わかりやすく言えば、一輪車に乗りながら頭にボールを乗せてバランスを取りながら焼きそばを食べるという必要性がほとんど説明できないコード。

困った事にC言語系だとこれが普通なんですが、こいつが多くのメンテナンス不能なコードとバグを生み出しているフリーザ級の悪の親玉。

途中でreturnの続き - Return to Saisse’s Wiki

だって Cは手続き言語ですから。だから「ながら」を「て」に読み替えるべし。

パラダイム変われば価値観は変わる。手続き言語でも「ながら」は好ましくありませんが、手続き言語ではこの例は「ながら」に当たらないように思います。そもそも極論OOPの価値観だと、条件分岐は悪でポリモーフィズムせよ！（Stateパターンとか）になるんじゃ...。（Smalltalkを見よ！）

途中return はダメで途中throw はOK という話は、Java の様に例外がとても良く設計されている言語ですとか、Pythonのような「例外をバンバンつかって制御を書いちゃえ」宗な言語では、そういうの全部 throw に置き換えちゃえば OK なので、禁止の害がそれほどでも無いかもしれません。「途中returnを禁止したことにより強調されるコードの腐臭がリファクタリングトリガーに使える」は十分旨みがありそうです。

ですが、ファウラー先生の「リファクタリング」でも、「ガード節による入れ子条件記述の置き換え」で、条件記述のネストを途中returnに置き換えるなど、途中returnは肯定的に扱われているので、たとえOOPという文脈であったって、あんまり一般化するような話でもないと思います。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)