{"meta":{"title":"コード例に注釈を付ける","intro":"長いコード例には注釈を付けて、その機能と、他の用途に合わせてカスタマイズする方法を説明することができます。","product":"GitHub Docs に投稿する","breadcrumbs":[{"href":"/ja/enterprise-server@3.21/contributing","title":"GitHub Docs に投稿する"},{"href":"/ja/enterprise-server@3.21/contributing/writing-for-github-docs","title":"GitHub Docs 向け執筆"},{"href":"/ja/enterprise-server@3.21/contributing/writing-for-github-docs/annotating-code-examples","title":"コード例に注釈を付ける"}],"documentType":"article"},"body":"# コード例に注釈を付ける\n\n長いコード例には注釈を付けて、その機能と、他の用途に合わせてカスタマイズする方法を説明することができます。\n\n## コードの注釈について\n\nコードの注釈でコード例の実行内容とその理由を説明することで、長いコード例をわかりやすくすることができます。 2 ペインのレイアウトで、コード例の横に注釈がレンダリングされます。そのため、長い注釈を書いてもコード自体は読みにくくなりません。 スニペットではなく、完全なコード例にのみ注釈を付けます。 コードの注釈はすべてのコード例に必須ではありません。明らかに必要な場合にのみ使ってください。\n\nコードの注釈はさまざまな読み手に役立ちます。 多くの場合、新しいユーザーには重要な概念を、経験豊富なユーザーには具体的な選択肢を説明するときにコードの注釈が使われます。\n\n新しいユーザーの場合、コードの注釈によって、コード例の概要にとどまらず、友人や同僚から指導を受けているかのように各コード行の実行内容を理解できます。\n\n経験豊富なユーザーの場合、コードの注釈はコード例を理解し、自分のニーズに合わせて調整するのに役立ちます。 コードを特定の方法で記述した理由を注釈で説明し、原理を明確にすることができます。\n\n1 つの記事で複数のコード例に注釈を付けることができますが、注釈を付けるたびに記事の複雑さが増し、スクリーン リーダーを使うユーザーにとっては反復的なナビゲーション タスクが追加されることに注意してください。 1 つの記事に複数のコード例がある場合は、それらを 1 つの例にまとめることができるかどうかを検討してください。\n\n## コードの注釈の有効化と追加\n\n1. 記事の `layout: inline` frontmatter プロパティを指定します。\n1. 三連バックティックを使用してコード例を作成します。\n1. コード例の三連バックティックの後に、言語を指定し、`annotate` を後に付けます。 たとえば、` ```yaml annotate` または ` ```ruby annotate` です。\n1. コード例内にコメント タグ (`#`、`//`、<code><&#33--</code>、`%%`) を使って注釈を追加します。 コード サンプルを記述した言語のコメント タグを使う必要があります。 たとえば、YAMLは`#`、JavaScriptは `//` です。\n   * 注釈を付けたコード例は、1 行の注釈で始める必要があります。 コードの先頭行に注釈を追加したくない場合は、空の注釈で始めることができます。\n   * 注釈は、コメント タグの下の行から、次のコメント タグまたはコード ブロックの末尾までのコード行に適用されます。\n\n### 注釈の規則\n\n次の規則は、すべてのコードの注釈に適用されます。\n\n* `/*` などの複数行スタイルのコメントはサポートされていません。\n* コードの注釈を開始するシンボルとコメントの間にはスペースを挿入する必要があります。\n  * **以下を使います:**`# comment`\n  * **以下は使いません:**`#comment`\n* 空の注釈を作成するには、後ろにテキストを入力せずにコメント タグを挿入します。 空の注釈は、サンプルの一部の行に注釈が不要な場合に便利です。\n* 先頭 `#!` の文字列はコード ブロックにレンダリングされ、コメントとして扱われません。\n* コメント タグの後にあるものはすべて Markdown で解析されます。 リンク、バージョン管理、その他のスタイル設定は、Markdown で記述されたかのようにレンダリングされます。\n* 複数の連続するコメントで 1 つの注釈が作成されます。\n* コメント タグで始まらず、空であるかスペースのみを含む行は無視されます。\n* コード セクションは 1 行のコメントで始める必要があります。 コード行の先頭行 (またはセクション) に注釈が必要ない場合は、テキストを含まないコメント タグを使って空の注釈を作成できます。\n* HTML スタイルの場合、構文の強調表示を維持するために注釈の後に閉じタグ `<!-- -->` を含める必要があります。\n\n## コードの注釈のベスト プラクティス\n\nコード ブロックの前に導入部を置いてコード例の全体的な目的を紹介し、注釈を使って各コード行の実行内容とその理由を説明します。\n\nコードの注釈はわかりやすさを優先すると同時に、できるだけ短くするように心がけます。 ユーザーは作業の基礎としてコード サンプルを使うので、注釈を参考にしてサンプルの記述内容と他の用途に合わせて調整する方法を理解できるようにします。\n\nコードの注釈を記述するときは読み手を考慮し、例を特定の方法で記述した理由を誰でもわかると想定しないでください。\n\n注釈を使うと、注釈を付けたコードに想定される結果を示すことができます。ただし、コード例全体の結果は、コード例の導入部または例の後で説明するなど、読み手にとって最適な方法で示す必要があります。\n\nコード例を変更した場合は、すべての注釈が引き続き有効であることを確認します。\n\n## 注釈付きコード例の例\n\n次の例は、レンダリングされたコードの注釈がどのように表示されるか、またそれらを作成する生のコードを示しています。\n\n### レンダリングされた例\n\n次のコード例は、pull request が開かれたときにウェルカム コメントを投稿するワークフローを示しています。\n\n```yaml annotate\n# The name of the workflow as it will appear in the \"Actions\" tab of the GitHub repository.\nname: Post welcome comment\n# The `on` keyword lets you define the events that trigger when the workflow is run.\non:\n  # Add the `pull_request` event, so that the workflow runs automatically\n  # every time a pull request is created.\n  pull_request:\n    types: [opened]\n# Modifies the default permissions granted to `GITHUB_TOKEN`.\npermissions:\n  pull-requests: write\n# Defines a job with the ID `build` that is stored within the `jobs` key.\njobs:\n  build:\n    name: Post welcome comment\n    # Configures the operating system the job runs on.\n    runs-on: ubuntu-latest\n    # The `run` keyword tells the job to execute a command on the runner.\n    steps:\n      - run: gh pr comment $PR_URL --body \"Welcome to the repository!\"\n        env:\n          GH_TOKEN: $\n          PR_URL: $\n```\n\n### 生のコード例\n\n    The following code example shows a workflow that posts a welcome comment on a pull request when it is opened.\n\n    ```yaml annotate\n    # The name of the workflow as it will appear in the \"Actions\" tab of the GitHub repository.\n    name: Post welcome comment\n    # The `on` keyword lets you define the events that trigger when the workflow is run.\n    on:\n      # Add the `pull_request` event, so that the workflow runs automatically\n      # every time a pull request is created.\n      pull_request:\n        types: [opened]\n    # Modifies the default permissions granted to `GITHUB_TOKEN`.\n    permissions:\n      pull-requests: write\n    # Defines a job with the ID `build` that is stored within the `jobs` key.\n    jobs:\n      build:\n        name: Post welcome comment\n        # Configures the operating system the job runs on.\n        runs-on: ubuntu-latest\n        # The `run` keyword tells the job to execute a command on the runner.\n        steps:\n          - run: gh pr comment $PR_URL --body \"Welcome to the repository!\"\n            env:\n              GH_TOKEN: $\n              PR_URL: $\n    ```"}