「○○チェック」というコメントが並んでいて、各コメントごとにreturnが用意されていて、浅いインデントばかりの平らなコードが続いていて、returnをかいくぐった後に本題が始まるようなコードをよく書く人。
それと、「この場合、以降の処理は不要だから」という理由でreturnを多用する人。
returnの多用で副処理は「入口は1つ、出口はたくさん」という不恰好な構造になる。というか構造化プログラミングになってない。
returnは副処理を終えるコード。副処理単位ではなくブロック単位でプログラムを組まないと、変数のスコープだって適切に設定できないはず。
returnを多用する人のコードには無駄な変数や不要になったのに存在し続ける変数が多いんじゃないだろうか。無理に処理を減らそうとすれば無駄な変数が増えるのかも知れない。
そもそも「チェックに引っかかる」＝「前提条件違反が頻発する」ような設計が良い訳ない。
無駄だし。
禁止するよりも導くことを考えないと。
適切なクラス定義、アサーション、コメント、アプリケーションハンガリアン…など。
省処理化のほうは「途中で中断できる」ということ。これは「分割可能な処理の集まりだけど、部分的に共通してる」ということで1つにまとめてしまう、設計無視・実装偏重な考え方じゃないんだろうか。
returnが多いコードは詳細設計から見直す必要があるのかも知れない。
