web-dev-qa-db-ja.com

コードの可読性を定義するものは何ですか？

重複の可能性：
読みやすく、保守が容易なコードを書いたかどうかはどうやってわかりますか？

可読性は、保守性、理解のしやすさ、使いやすさに関する理由から、特定のコードの品質を定義する最も重要な尺度であるとよく言われます。

プログラムのソースコードのコンテキストで、Wordの定義読み取り可能は何ですか？どのような決定的な側面がありますか？コードの読みやすさ？

判読可能なコードのコード例と、なぜそれが判読可能であるかについての推論に感謝します。

code-qualitylanguage-agnosticreadability
8
zxcdw

私にとって可読性とは、コードが論理的にわかりやすいことを意味します。

  1. インデントとフォーマットの標準に従っているため、コードとその構造が明確に表示されます。
  2. 変数は意味を表す名前が付けられているため、意図を伝えます。
  3. 必要な場所にのみ存在するコメントは簡潔で、標準形式に準拠しています。
  4. ネストされたifステートメントの代わりにガード句が使用されます。
  5. 言語の機能は巧妙に使用されており、コードのコピーアンドペーストではなく、反復と再帰を利用しています。
  6. 関数は短く、要点がありますと1つのこと。
  7. 柔軟性を維持しながら、間接化を可能な限り最小限に抑えます。

判読不能：

        try:
          if item[1][2]=='1':
            qtytype='0'
            qty=str(item[1][0])
            items=item[1][0]
            amt='0.0'
            tot_amt=str(float(item[1][1])/100)
#              tot_amt=str(float(int(item[1][0])*int(item[1][1]))/100)
          else:
            qtytype='1'
            items=item[1][0]
            amt='0.0'
            tot_amt=str(float(item[1][1])/100)
            qty=0
            for entry in item[1][4]:
              qty+=entry[0]
        except TypeError:
          eType, eValue, eTraceback = sys.exc_info()
          print >> sys.stderr, time.strftime("%Y-%m-%d %H:%M:%S"), str(traceback.format_exception(eType,eValue,eTraceback))

読み取り可能：

item_approved = (item['approved'] == '1' and item['active'] == '1')

if item_approved:
    try:
        db_item = item.get_db_record(item['id'])
    except DoesNotExist:
        db_item = item.create_db_record(**item)

    item.approve(db_item)
    db_item.save()

    publish_event(item.events.APPROVAL)
10
asthasr

http://c0x.coding-guidelines.com/Introduction.pdf のセクション9（39ページ）は、C言語コーディングガイドラインの背景を示しています。これは、社会学と心理学の研究に関する参考文献です。それは「なぜコードが読めるはずなのか」という問題に対処していますが、可読性自体に対処しています。場所によっては少し「学問的」ではありますが、私はそれが非常に興味深いことに気づきました。

5
Duncan

同様の質問が以前に回答されています。たとえば https://stackoverflow.com/questions/550861/improving-code-readability を参照してください。

読み取り可能なコードは、その意図を読者に明確に伝えるコードです。読み取りできないコードは、理解するのに時間がかかり、欠陥の可能性が高くなります。

読みやすさを向上させるいくつかのこと：

  1. 空白を使用して、コードの異なる領域を分離します。たとえば、「if」ステートメントのようなコードブロックをインデントします。メソッド/関数またはメソッド/関数内の関連するコード行の間には空白行を残します。これにより、文字が読み取られる前でも、脳はコードを分離できます。
  2. 意味のある変数とメソッド/関数/クラス名を使用してください。言語の標準的な慣行に従い、可能であれば問題のあるドメインの用語を使用してください。何かの意味と使い方は、その名前から明らかです。名前も一貫している必要があります（get_X（）、LoadYFromDatabase（）、getVar（Fields.Z）ではなく、GetX（）、GetY（）、GetZ（）））;
  3. 効果的にコメントする。明白なコメントを避けます（「GetX（）メソッドはxの現在の値を返します」）。コメントには、コードの意図、コードの他の部分との関係、および想定（「引数aはnullにできません。aがnullの場合、コードは例外をスローします」）を記載する必要があります。
  4. 言語、ライブラリ、または問題空間の確立された設計パターンに従う。たとえば、繰り返しコード（DRYまたはDot Repeat Yourself）と呼ばれます）は避けてください。これは、読者が相違点を探したり、修正する正しいコードを見つけたりするため、時間の無駄になります。
  5. シンプルに保つ（KISSの原則）。たとえば、時期尚早または不要な最適化を避けます。最適化の場所がありますが、読みやすさに影響を与えることなくコードを最適化できることがよくあります。

間違いなく最も重要な側面は一貫性です。読者が何を期待し、どこを見ればよいか知っていると、コードを理解しやすくなります。たとえば、プロジェクトで競合する変数の命名スタイルとコメントスタイルを使用している場合、読者は新しいスタイルやコンテキストの切り替えを学ぶために精神的な労力を浪費する必要があります。

コードの作成者は、コードに投資しているか、問題を深く理解して一歩下がって他の人の目を通してそれを見ることができないため、読みやすさの判断が難しいかもしれません。コードレビューはここで役立ちます。

すべてのコードが常に読み取り可能であるとは限らないことに注意してください。開発者は、よく知らないライブラリを使用して疲れている場合、急いでコードを書かなければならないことがよくあります。読みやすさが悪い場合は、技術的な負債のように扱い、リファクタリングする必要があります。

2
akton