技術者の評価を下げる「悪い」コメントに注意しよう
ソフトウェアの受託開発や、オープンソースのプロジェクトでは、ソースコードが他の技術者の目に触れる。そのため、ソースコードから開発者の技術力が評価されやすい。 ソフトウェアの開発者は、モジュール分割やクラス設計には全力を傾ける。最近では、設計の完成度を高めるために、実装の後でリファクタリングを行うことも珍しくない。 だが、設計の善し悪しにこだわる開発者でも、ソースコードに書くコメントの品質までは、配慮が及ばないことが多い。コメントは本質的なものではないので、つい気を緩めてしまうのである。 ところが、開発者の希望に反して、ソースコードの読み手が印象を受けやすいのは、コメントの品質である。ソースコードから設計を読み解くのは容易ではないが、日本語や英語で書かれているコメントは目に付きやすい。 優秀な技術者の書いたソースコードでも、驚くほど「悪い」コメントが書かれていることがある。そのようなソースコ
ブール値を返すメンバー関数の命名規則
関数の名前の付け方は人それぞれですが、使う単語が同じなら、関数の名前はほぼ同じものになると思います。例えば、サイズをセットする関数の名前を、「set」と「size」という単語を使って考えると、ほぼ全員が「SetSize」と答えるでしょう。「SizeSet」「SizeToSet」「SizeSetted」「SettingSize」といった名前を考える人は、ほとんどいないと思います。 ところが、真か偽かのブール値を返す関数の名前は、混乱することが多いようです。 ここでは、Java言語で採用されている命名規則と、その解釈の仕方を紹介します。 関数名が混乱する例 ブール値を返す関数では、「Is○○」という名前を良く見かけます。例えば、中身が空っぽかどうか、の判定をする関数には、IsEmptyという名前が良く使われます。MFCのCStringクラスや、JavaのListインターフェースなどにも、IsE
テストファーストの弊害
テストファーストは、XP（エクストリームプログラミング）の中でも特に広く浸透したプラクティスの１つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根本からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
