Closed3
読書メモ: A Philosophy of Software Design
otokunaga2
上記の本がとても分かりやすく、感銘を受けたため読書メモを残す。
13.6
コメントにはhowではなくwhatを書く。
whatだけでなくwhyを書くのも大事。
13.7
クロスモジュール、複数のモジュールにまたがるドキュメントは難しい。
15
コメントを最初に書く
多くの開発者が開発とテスト後にコメントを開発後に記述します。これはクオリティの低いドキュメントをもたらします。
16
プログラムを修正するたびに少しずつシステム設計をよくする方法を見つけてみて下さい。デザインを改善していない場合、恐らく悪化させているでしょう。
16
全ての開発組織はクリーンアップとリファクタリングに一部ついやすことを計画する必要があります。この仕事は長い目で見た時にペイするでしょう。
コメントはコードの近くでメンテナンスすること
コードをを変更した時よくコメントをアップデートし忘れがちであり、それはもはや正確なコメントとなっていません。
このように最新にアップデートされてないコメントは読者にとってフラストレーションが溜まるようになってしまいます。
otokunaga217 consistency
一貫性はコードの読解を容易にし、システムの複雑さを減らすパワフルなツールです。
otokunaga218 コードは明白であるべき
プログラムは空白書式にて設定される。
以下は空白を利用しない例です。2つの例を比べてみる。一つ目の例だとスペースがうまく使われていないため、パラメータがいくつあるかわかりません。2つ目の例ではスペースを上手く利用しており、パラメータがいくつあるのか1つ目の例よりも明白である。
@param numThreads The number of threads that this manager should * spin up in order to manage ongoing connections.
The MessageManager * spins up at least one thread for every open connection, so this * should be at least equal to the number of connections you expect
@param numThreads *
The number of threads that this manager should spin up in * order to manage ongoing connections. The MessageManager spins * up at least one thread for every open connection, so this * should be at least equal to the number of connections you
@param handler
Used as a callback in order to handle incoming * messages on this MessageManager’s open connections. See * {@code MessageHandler} and {@code handleMessage}
このスクラップは2022/05/05にクローズされました