📖 220129クリアコードDAY 06

1286 ワード
本屋 レコーダなし 元手を出す テキストリンク
📖 読み取り範囲
4注記(p.67～p.94)
🧠 本の中で覚えたい内容
  • 注釈が長くなるほど、コードから遠くなります.長くなるほど、完全に間違っている可能性も大きくなります.理由は簡単だ.プログラマーのメンテナンスとメンテナンスコメントは実際には不可能です.
  • 表現力が豊富で、簡潔で、ほとんど注釈のないコードは複雑で、乱れていて、注釈の多いコードよりずっと良いです.
  • の意図、警告結果、またはテスト中であることを示す場合にのみ使用します.
  • があるが、少なくとも1つの注釈の誘惑から抜け出し、コードを整理しなければならない.より良い、より幸せなプログラマーになる近道です.
  • 関数または変数で表すことができる場合は、
    • にコメントしないでください.
  • の著者の名義でコードを汚染する必要はありません.上記の情報は、ソースコード管理システムに格納することが望ましいことを改めて強調する.
  • 注釈で処理されたコードのように、嫌な慣例も少ない.
    • 🤔 読んだ感想や考え
    次の2つのコードの例を示します.どちらがいいですか.
    // 직원에게 복지 혜택을 받을 자격이 있는지 검사한다.
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))
⬇️ 변경 후
if (employee.isEligibleForFullBenefits())
    この一節を見て、私はとても驚いて不思議に思った.この例を通して、作者は作者の意図の方式が何を意味するかをはっきり理解して、本当のすべてはできるだけ短く書かなければなりません.この間if文で複数の場合、そのようにコードを記述していたからです.どうして一度も関数化を考えなかったのですか.
  • 履歴を記録したコメントや、あまりにも当たり前の内容のコメントは書かないでください.
    これまで、Nomad Coder、Java、例題を勉強していたとき、後で復習したときに理解しやすいように、当たり前の注釈を書きました.今考えると,コードの意味をより直感的に理解できるように記述すれば,最初から注釈を行う必要はない.これからは理解できる名前で書く習慣を身につけなければなりません.
    • 🔎 疑問や理解できない内容

    • ✍🏻 感想3行ダイジェスト
  • この間私が書いたすべてのコードは汚いコードです.
  • 今回の例題のコードを見て、作者が考えているCLIN CODEについて少し理解しているような気がします.
  • 以降は、コメントを必要とせずにコードをきれいに書いてみましょう.注釈があるということは、コードを理解するには最終的に追加の説明が必要であることを意味します.
    • PhoneGap API紹介:デバイス
    あなた自身の概念を書く方法?第1部