Ten Essential Development Practices (from Perl Best Practices)

perl

Perl Best Practices: Standards and Styles for Developing Maintainable Code
Timもお勧めのPerl Best Practices: Standards and Styles for Developing Maintainable CodeからTen Essential Development Practices。
例として記述されているサンプルコードや周辺環境はperlですけど、perl以外のプログラミング言語にも当てはまる、いい内容です。

  1. モジュールインターフェースをまず先に設計せよ
    • 汚い、複雑なインターフェースのモジュールは使われない
    • きれいなインターフェースを設計するには経験と創造性が必要
    • うまくできないならそのモジュールのテストケースから書き始めるのもいい
  2. コードの前にテストケースを書け
    • 出力フォーマットに気を使いながらprintした結果を目で追うより、Test::Simple使ったほうが楽。
    • Test::Simple使ったほうがコードが見やすいし、出力結果も簡潔(notがないか左はじを縦に見ていくだけ)。
    • Test::Moreもアルよ
    • Test::Tutorialに詳しい説明がある。
  3. モジュール、アプリケーション用に標準PODテンプレートを作成せよ
    • ドキュメント整備が嫌な理由は「白紙効果」にもよる
    • テンプレートがあれば開発者の作業は少量のコピペだけで済む
  4. リビジョン管理システムを使え
    • アンドゥ無しのエディタ、マージできないワープロソフトなんか使いたくないでしょ？
    • 昨日の変更を無理やり動作させるより、それより前の安定バージョンに戻してそこから始めるのもいいデバッグ技術
    • リビジョン内の最近の安定バージョンと問題となっているコードのdiffは問題を明らかにしてくれるかもしれない
    • リビジョン管理システムにはいろいろなものがあるけど、初めてならPragmatic Version Control: Using Subversion (Pragmatic Starter Kit)とEssential Cvsを手に取るのがいいかも
  5. 一貫したコマンドラインインターフェースを作成せよ
    • 機能追加のたびにオプション、引数等を加えていくと、一貫性が無くなる
    • あなたが提供する一連のプログラムのコマンドインターフェースに矛盾がなければ、コマンドの使い方をいちいち質問されることもなくなるかも
    • よく使われるコマンドラインインターフェースの例
      • ユーザは引数リストとその順番を覚えたくない。ファイル名以外のオプションは前置詞フラグで指定できるようにすべき
      • 異なる目的のファイルを複数指定できる場合は、ファイル名もフラグ付きで指定できるようにする
      • 接頭辞フラグは最大3文字まで
      • 長いフラグは--を使う
      • フラグ=値による値設定のサポート
      • 単一ハイフンの後の「まとめられた」単一文字フラグ(-v -l -x → -vlx)
      • 単一文字フラグの文字列版
      • "-"フラグを特別ファイルとして常に許可する(-が入力に指定された場合は標準入力、出力に指定された場合は標準出力を意味する)
      • "--"フラグをファイルリストとして常に許可する
  6. 首尾一貫したソースレイアウト(インデント)、それをperltidyで自動化する
    • 皆<<ここにあなたのコーディングスタイルを挿入>>が真のソースレイアウトだと信じている
    • 長期間合理的なコーディングスタイルを貫くことはよい訓練になる
    • 常にそのスタイルを使えるようになるには時間がかかる。そんな場合はperltidyを使うのはお手軽
  7. 段落ごとにコメントを
    • ひとかたまりの処理ごとにコメントあるのもよい
    • コメントには目的を書く。処理内容ではない(メモ:処理内容はソースをみればよい)
    • コメントよりも処理間の空行のほうがソースを見やすくするために重要
  8. 特定値のreturnやフラグセットのかわりに例外処理せよ
    • return値やフラグでのエラーハンドルの場合、開発者はそれを無視できてしまう
    • 関数内で例外処理していれば上位で気にする必要は無い
    • evalでまとめて囲めば戻り値チェックを外せるので、コードが見やすくなる
  9. デバッグを始める前に新しいテストケースを追加せよ
    • エラーレポートを受け取ったらまずそのエラーを再現する
    • エラーが発生することを確認してからソースを修正
    • 同様のエラーが起こると考えられるテストケースも追加する
  10. コードを最適化ではなく、ベンチマークせよ

個人的にはコマンドインターフェースとperltidy、例外処理の項目が特にためになりました。
あと他の言語から来た人間にとっては、状況ごとの基礎的な処理(ループとか条件判断とか)がまとまっている文章があると助かるんですけど、この辺りはやはり体で(コードを書いて)覚えるしかないんですかね。いまだにifとunlessの使い分けとか前に書くか後に書くか迷うことが多いです。Cと同様に書けば迷いはないんですけど、"らしく"ないなぁと思ってしまいます。