 |
|
|
| 1 2 3 次のページ
|
|
| はじめに
|
皆さんはコーディングがお好きですか？
プログラミングが好きでソフトウェア業界に入りプログラマになったのは良いものの、ソフトウェアやシステムを新規に設計して開発するのは稀で、現実には他人の書いたソースコードを触ることが多くはないでしょうか？
そして、いざ引き継いだソースコードを見て愕然としたことはないですか？例えば、以下のようなことに遭遇しませんでしたか？
- クラス名／メソッド名（do1、do2）／インスタンス変数名（a、w、t）の意味が分からない
- 同じような事が何度も書かれている
- メソッドの長さが1000ステップを越えている
- mainメソッドしか存在しない
|
表1：驚くべきソースコード
|
プログラマは、受け取ったソースコードを見て処理内容を推測します。手がかりは、プログラムの構成やメソッド名、変数名などです。
もし仕様書があれば、ソースコードを読み解くために利用できますが、仕様書とソースコードの内容があまりにも異なる時は、プログラムの方を正しいものとします。
そうやって、読み解こうとしたソースコードが複雑な場合、ソースコードに書かれた変数名やメソッド名の意味が分からない場合、メソッドの長さがある閾値を越えてしまう場合はそのソースコードを引き継いでメンテナンスするよりも、新しく書き直すことを選択してしまいます。
因みに、変数名やメソッド名を解りにくくすることは、難読化（Obfuscation）や曖昧化（Obfuscator）といいます。これらはソフトウェアプロテクションという分野として盛んに研究が行われています。世の中には難読化／曖昧化のための解析ツールもあります。
相手が理解しやすいように、良いソースコードを書くためには、どのようにすればよいのでしょうか？それは、次にあげる「コーディングの心得」を守ることです。
|
| コーディングの心得
|
プログラミングを上達させるためにもこのコーディングの心得は把握しておいてください。後で説明する箇所でも、もう一度宣言します。
- 見やすさを重視せよ
- ネーミングは分かりやすく
- サンプルを鵜呑みにしない
- 同じコードを二度書かない
- 役割は一つに
|
表2：コーディングの心得5ヶ条
|
私がプロジェクトでプログラミングする場合は、メンバーとこの5ヶ条を毎朝唱えてから仕事をスタートしようというような冗談が通じるような体制で、プロジェクトを進めています。
|
| 良いコードとは何か
|
コーディング規約を利用する目的は、ソースコードの品質をあげることだと思います。品質の基準を明確にしないで良い、悪いと話してもしかたありません。そこで、本連載の第1回目では、「良いコードとは」というテーマで話を進めていきたいと思います。そして、そのことが最終的に「心得5ヶ条」につながっていきます。
ここでは、「良いコードとは」どういったものなのかを考え、ソースコードを交えながら、悪い点を説明していきます。
では、良いコードとはどういったものでしょうか？良いコードだと思われる内容を表3に箇条書きで表します。
- 読みやすい
- 適切なコメント
- 速い、見た目がよい
- 修正個所がすぐに分かる
- 機能の追加・削除が楽
- バグが無い
- セキュリティが考慮されている
- 仕様を満たしている
- 落ちない
- 自分だけがメンテできる（仕事に困らない）
|
表3：良いコードとは？
|
最後の項目は冗談ですが、「良いコード」とは、プログラムの品質と密接に関わっていることが分かると思います。
|
1 2 3 次のページ
|
|
|
|
|
|
著者プロフィール
株式会社電通国際情報サービス 高安 厚思
株式会社電通国際情報サービス 開発技術センター
Java（J2EE）／オブジェクト指向の研究開発やプロジェクト支援、開発コンサルティングに従事。モデル、アーキテクチャ、プロセスが探求対象。今回は Javaコーディング規約2004の仕掛け人。
|
|
著者プロフィール
株式会社電通国際情報サービス 東田 健宏
株式会社電通国際情報サービス 開発技術センター
CTI、Webアプリの開発経験を経て、現在は主にプロジェクトマネジメント支援、プロセスエンジニアリング、ソフトウェア工学研究開発に従事。最近はコーチング、ファシリテーションといったヒューマン系スキルに興味を持ち日々修得に努めている。
|
|
著者プロフィール
株式会社 エー・ピー・アイ 森田 健
コードが単純になるには？見やすいコードを書くには？を日々模索しています。「コードがドキュメントだ」が、口癖な他称人間コンパイラ。
|
|
|
|
|
|
