>>491
なるほど、その通りかもしれません。
パターンＡで回数を返す部分をインラインにすれば、ソースはすっきりしますし、保守性も良いですね。

>>492
ということは、jのループの前に、ループ回数を決めるための条件判断が必要ですよね？
さらに、Jのループ内でも前処理を決定するための条件判断がいるわけで、無駄じゃないですか？
bを配列にしたのは、ループ内での条件判断を一回にするためです。

>>493
…すみません、気づきませんでしたが、どう違うんでしょうか？

>>495
ソース内に、同じ処理を行う部分が複数箇所存在するのは、可能な限り避けるべきだと思います。
「共通処理」というのが単一の関数ならまだ良いですが、もしこの処理が数十行に渡るものだったりすると大変なことになります。
変更する場合にはすべての箇所に変更が必要ですし、保守性も悪すぎるので…。

>>498
その通りです^^

>>494
上で書いた>>495さんへの回答で指摘した問題点は「パターンＢで【共通処理】を関数に切り分ける」
ということで、確かに解決するのですが…。

その共通処理が重い（処理速度ではなく、重要度が）場合や、後始末が必要になる場合
（例えば、メモリをアロケートしたり、スタックを操作したり、ファイルアクセスをしたり）、
複数箇所に存在させるのがどうかなーと思っています。

例えば、application_main() とか screen_draw() とか、check_keyboard() とか wait_vsync() とか、
ソース中に何箇所も書きたくない関数ってあると思うんですけど、
「共通処理」は、結構それに近いものがあったりするので…。