なるべく垂直な一本の線が良い、Javaプログラムの正常処理の流れ
ケンジロウJavaプログラムの正常処理の流れは、Javaソースコードにおいてどんな風に見えますか？
Javaプログラムの正常処理の流れは、上から下へ向かう垂直な一本の線に見えます。
Javaプログラミングでは、無駄なif文を記述しないなど、わかりやすさを意識してプログラムを書きましょう。
そうしたら、正常処理の流れがわかりやすいJavaソースコードになります。
なるべく垂直な一本の線が良い、Javaプログラムの正常処理の流れ
Javaソースコードにおいて「正常処理の流れ」は、以下のような線が良いと思います。
- なるべく、上から下への垂直な一本の線
- なるべく、左側にある線
- なるべく、長さが短い線
次のようなイメージの線です。
青線が、「正常処理の流れ」を示しています。
処理内容を理解しやすい、「正常処理の流れ」が一本の直線であること
「正常処理の流れ」が一本の直線であることは、「処理の流れ」が一つだけ、ということを表しています。
Aの場合の処理、Bの場合の処理という風に、「2つ以上の処理の流れ」を理解する複雑さは、ありません。
「処理の場合分け」が少ないソースコードは―― if文が少ないソースコードは ――単純であり、処理内容を理解しやすいと思います。
「if文の字下げ」が少ない、「正常処理の流れ」が左側にあること
「正常処理の流れ」が左側にあることは、処理の分岐が少ない（例：if文か少ない）状態を、表しています。
if文で処理を分岐する場合、
if文の条件に対応する処理を、右側に字下げして書くことが多いです。
よって、「正常処理の流れ」が左側にあることは、「if文の字下げ」が少ないソースコードだと、言えます。
例：if文の中に、別のif文があるという、if文の入れ子が少ないソースコード。
「if文の字下げ」が少ない場合も、「正常処理の流れ」を理解しやすいです。
ソースコードの理解を妨げる、ソースコードの字下げが深いこと
Javaのソースコードでは、字下げ（インデント）を使ってプログラムの構造を明確にすることが、推奨されています。
Java言語に限らず、多くのプログラム言語において、ソースコードで字下げを行うことが一般的です。
字下げは、制御文やブロックの範囲を、視覚的にわかりやすくするために行われます。
しかし、字下げが深くなりすぎると、逆にコードの可読性や保守性が低下するデメリットがあります。
以下に、字下げが深い場合のデメリットをいくつか挙げます。
ソースコードの幅が広くなる
字下げが深いと、ソースコードの幅が広くなります。
これは、画面や紙に収まりきらない場合や、改行を入れる必要がある場合に、
コードの見た目が乱れる原因になります。
また、コードの幅が広くなると、「正常処理の流れ」がまっすぐな線になりません。
右下方向に伸びている階段みたいな線になります。
このような場合、「正常処理の流れ」を理解しづらくなります。
ソースコードのネスト構造が複雑になる
字下げが深いと、ソースコードのネスト構造が複雑になります。
これは、ソースコードの理解やデバッグを難しくする原因になります。
ネスト構造が複雑になると、条件分岐やループの入れ子が多くなります。
条件の有効範囲やループの終了条件を、把握しにくくなります。
また、ネスト構造が複雑になると、変数のスコープや可視性も複雑になります。
意図しない値や挙動を引き起こす可能性が高まります。
ソースコードの再利用性が低くなる
字下げが深いと、ソースコードの再利用性や拡張性が低くなります。
これは、ソースコードのモジュール化や関数化を妨げる原因になります。
字下げが深いということは、一つの関数やブロックに多くの処理を詰め込んでいる、ということです。
ソースコードのある範囲に多数の処理を詰め込むことは、ソースコードの再利用性を低下させるだけでなく、新しい機能や変更を加える際にも影響範囲が広くなります、
ソースコードの修正による影響範囲が広いことは、バグやエラーを引き起こしやすくなります。
ソースコードの字下げの深さは、4段階以下にしましょう
以上のように、Javaのソースコードの字下げが深い場合には、様々なデメリットがあります。
そのため、字下げは適切なレベルで行うことが重要です。
一般的には、字下げの深さ（ネストの深さ）は、4段階以下にすることが推奨されています。
ただし、これはあくまで目安であり、状況に応じて柔軟に調整する必要があります。
字下げの深さを減らす方法としては、以下の方法があります。
- 関数やメソッドを分割する。
- 条件分岐を単純化する。
- 早期リターンを使う。
コードの可読性を高める、早期リターン
プログラミングにおける早期リターンとは、メソッドの処理を途中で終了させることです。
早期リターンは、return文を使って条件分岐のネストを減らし、コードの可読性を高めるテクニックです。
早期リターンの一般的なパターンは、以下のようになります。
public void someMethod() {
// 前提条件をチェックする
if (条件が満たされない場合) {
return; // メソッドを終了する
}
// メインの処理を行う
…
}メインの処理を行うソースコードにおいて、if文の条件指定の個数を減らせます。
処理全体を一覧しやすい、「正常処理の流れ」を示す線が短いこと
「正常処理の流れ」を示す線が短いことも、プログラム処理を理解しやすくします。
処理する項目数が少なくて、処理全体を一覧しやすいから（眺めやすいから）です。
なるべく行数の少ないソースコードを、記述しましょう
「正常処理の流れ」を示す線が短いことは、ソースコードの行数が少ないことを意味します。
個人的には、ソースコードの行数が少ない方が、プログラムの不具合も少ない、と思っています。
一般的に、ソースコードの行数が多いほど、プログラムの複雑さや結合度が高くなり、不具合が発生しやすくなる、と言われています。
確かに、長文のソースコードほど複雑である、と言える気がします。
他のプログラマーが書いた、とても長いソースコードを読んだ際、どんな処理をやっているのか、よくわからないことがありました。
しかし、ソースコードの行数だけでは、プログラムの品質を正確に評価することはできない、と言われています。
なぜなら、ソースコードの行数は、以下の要因で大きく変わるからです。
- プログラミング言語
- コーディングスタイル
- コメントや空行の有無
以上より、プログラミングする際は、
なるべく行数の少ないソースコードを記述すると心がける、という感じで良いです。
無駄のない洗練されたソースコードを書くようにしたら、アプリの品質が良くなると思います。
Javaソースコードにおいて、「正常処理の流れ」を示す線の例
実際のメソッドについて、正常処理の例を示します。
ここではまず、青線を見てください。
プログラムの詳細を、理解する必要はありません。
※ソースの内容がさっぱりわかりません、という感想をいただきました（2002年10月）。
ここではプログラムや利用しているクラスについて、説明がありません。
よって、どんな処理をしているのか？わからないのが自然なことだと思います。
詳細を気にしないでください。
このメソッドにおいて、正常処理の流れ――青線――は、
- 上から下に行く直線のような感じ
- 各直線が、なるべく左側にある感じ（無駄なif文がない感じ）
になっている、と思います。
よって、「正常処理の流れ」を理解しやすいメソッドになっている、と言えます。
