magazine.gifきれいなコードを書くための鉄則

第1部 コーディングルールの光と影

  • 鉄則その1 メソッド(関数)は○○行以下に!?
    • 行数を制限するコーディングルール
    • メソッド分割
    • 行数制限は万能?
    • まとめ
  • 鉄則その2 命名規則の考え方
    • かつての命名規則
    • プログラミング言語による制限
    • 何の名前か
    • 名前のスコープ
    • 言語の問題
    • 名前の省略
    • 検索性
    • まとめ
  • 鉄則その3 わかりやすいコードを書く
    • 条件式(等号)
    • 条件式(不等号)
    • コメント
    • (カッコを付ける)
    • {カッコを付ける}
    • breakとcontinue
    • まとめ
  • 鉄則その4 見た目を美しく
    • インデントと括弧の位置
    • 1行の文字数
    • 空白の入れ方
    • まとめ

第2部 コーディングルールに書けないあんなこと・こんなこと

  • 鉄則その5 再帰呼び出しの使いどころ
    • ファイルの一覧を表示する
    • 階乗を計算する
    • ハノイの塔と木構造
    • まとめ
  • 鉄則その6 探索アルゴリズムの選び方
    • 逐次探索
    • 二分探索
    • ハッシュテーブル
    • データベース
    • まとめ
  • 鉄則その7 整数型の使い方
    • どの型を使うべきか
    • 整数型いろいろ
    • まとめ
  • 鉄則その8 フラグとビットフィールドは必要最小限に
    • フラグ
    • 論理型
    • ビットフィールド
    • まとめ
  • 鉄則その9 文字と文字列の落とし穴
    • 文字集合と符号化方式
    • UTF-16とサロゲートペア
    • 内部コードと外部コード
    • まとめ
  • 鉄則その10 日付と時刻の持たせ方
    • 蔵書リスト作成プログラムと蔵書検索プログラム
    • Java APIにおける日付と時刻
    • タイムゾーンに気をつけよう
    • 場合に応じた日付の持たせ方
    • まとめ

第3部 上手に楽をするために

  • 鉄則その11 言語を選ぶ
    • どんな言語を使ったらいいか
    • とりあえずCで書いてみる
    • やはり文字列はJavaのほうが楽
    • Perlにすればもっと簡単?
    • awk(おーく)は言わねえ・・・・・・
    • コードを書かずに済ます
    • まとめ
  • 鉄則その12 デザインパターンをどう使うか
    • デザインパターンとは
    • デザインパターンの例:Iteraatorパターン
    • デザインパターンの例:Adapterパターン
    • デザインパターンをどこまで意識すべきか?
    • まとめ

第4部 プログラムはでき上がっても、それで終わりではない

  • 鉄則その13 メソッドやクラスの変更と廃止
    • 名前が公開される範囲とその影響
    • メソッドを廃止すると・・・・・・
    • deprecated(非推奨)
    • クラス名やメソッド名の変更
    • まとめ
  • 鉄則その14 開発モデルを決める
    • ウォーターフォールモデル
    • 小規模から大規模へ
    • 仕様が変更になったら
    • まとめ
  • 鉄則その15 リファクタリングを実行する
    • 仕様と実装の狭間で
    • リファクタリングとは?
    • オブジェクトによるデータ値の置き換え
    • 「委譲による継承の置き換え」と「継承による委譲の置き換え」
    • リファクタリングとテスト
    • 設計が先か、とりあえず実装か
    • まとめ

第5部 きれいなコードを書くための最後の鉄則

  • 鉄則その16 コミュニケーションの取り方
    • コミュニケーションも大切
    • コメント-プログラマ同士のコミュニケーション
    • コードを読む
    • 最後に
    • まとめ

索引

コラム索引

  • Javaからデータベースへの接続
  • ウォーターフォールモデル以外の開発モデル
  • Javaのアクセサ
  • ポリモーフィズムによる条件記述の置き換え