|
||||||||||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||||||||||
| レベル2:外部仕様を満たすが読みにくいプログラム | ||||||||||||||||||||||||||
|
レベル2のプログラムのソースコードは、レベル1の問題点を克服しただけであり、コーディング規約が守られておらず、ソースコードの可読性が悪いものとなっています。 |
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
レベル2のプログラムのソースコードには主に以下のような問題があります。
|
||||||||||||||||||||||||||
|
表7:レベル2のソースコードの問題点 |
||||||||||||||||||||||||||
| 不要なコメント(削除漏れ) | ||||||||||||||||||||||||||
|
コメントは必要なもののみを記述します。 「//ここは削除しないこと。2001.5」や、「//ここは、これから実装する 2002.5」 といったコメントは、それを読んだプログラマをミスリードしかねません(13行目、28行目)。 また、修正前のコードを、コメントとして残しているソースコードがありますが、こういう死んだコードは削除して下さい。生きているコードが判別しづらくなります(20行目)。 |
||||||||||||||||||||||||||
| 宣言がまとまっていない | ||||||||||||||||||||||||||
|
変数がソースコード上に分散しています(12行目、23行目)。 これでは仕様が変更された場合、ソースコード上に分散して存在する変数を探し出さなければなりません。 仕様の変更や修正が行いやすいように、変数を意味のあるグループにまとめて、クラスの先頭の方で宣言するようにして下さい。 |
||||||||||||||||||||||||||
| 不要な改行 | ||||||||||||||||||||||||||
|
「BufferedReader br = new BufferedReader(new InputStreamReader(System.in));」は改行されているものの、改行位置が良くなく見づらくなっています(17〜19行目)。 長すぎる行は見やすさを考慮して、コンマや演算子の後で改行します。 ここでコーディングの心得が効いてきます。 コーディングの心得、5ヶ条「見やすさを重視せよ」
|
||||||||||||||||||||||||||
| クラス名、メソッド名、変数名に意味が無い | ||||||||||||||||||||||||||
|
ネーミングの良し悪しは、ソースコードの可読性に非常に大きな影響を及ぼします。 問題のソースコードではクラス名「CS」、変数名「bz」や「p」が、いったい何を表すのか分かりません(7行目、12行目、23行目)。 クラス名「CS」は「カメラショップ」の略で、変数名「p」が「価格」を意味するのであれば、下手に略したりせずにクラス名を「CameraShop」に、変数名を「price」としたほうが分かりやすくはないでしょうか? ネーミングは大変難易度の高い作業です。 例えば、数値の「5」を「FIVE」と置き換えることはナンセンスです。その数値が消費税を表すのであれば、それは「TAX」などと命名されるべきです。ネーミングは読んで内容が理解できるように、その本質を表す言葉を選ぶことが大切です。 ここでコーディングの心得が効いてきます。 コーディングの心得、5ヶ条「ネーミングは分かりやすく」
|
||||||||||||||||||||||||||
| 次回は | ||||||||||||||||||||||||||
|
今回はコーディングのポイントとして5つのレベルに分類し、その内の最初のレベル2についてまで説明しました。次回はレベル3から説明します。 |
||||||||||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||


