|
| 1 | +# Code annotations |
| 2 | + |
| 3 | +Code annotations help explain longer code examples by describing what a code example does and why. The annotations render next to the code samples in a two pane layout, so we can write longer annotations without making the code itself difficult to read. We only annotate full code examples, not snippets. Code annotations should add value when used and are not required for every code sample. |
| 4 | + |
| 5 | +Code annotations can be helpful for a variety of audiences. Often, code annotations will be used to explain key concepts to new users or specific choices to more experienced users. |
| 6 | + |
| 7 | +For new users, code annotations are a way to go beyond the high level overview of a code example and explain what each line of code does so that someone can understand the code as if a friend or coworker were guiding them through it. |
| 8 | + |
| 9 | +For more experienced users, code annotations can help them understand a code example and then tailor it to their specific needs. Annotations can explain why code was written a certain way so that the fundamentals are clear. |
| 10 | + |
| 11 | +## Enabling and adding code annotations |
| 12 | + |
| 13 | +1. Specify the `layout: inline` frontmatter property for the article. |
| 14 | +1. Create a code example using triple backticks. |
| 15 | +1. Specify a language for the code example after the triple backtick, followed by `annotate`. For example, ` ```yaml annotate` or ` ```ruby annotate`. |
| 16 | +1. Add annotations using comment tags (`#`, `//`, `<!--`, `%%`) within the code example. Annotations apply from the line below the comment to the next comment tag or the end of the code block. |
| 17 | + |
| 18 | +An annotated code example must start with a single line annotation. You can start with a blank annotation if you do not want to add an annotation to the first line of code. |
| 19 | + |
| 20 | +You must use the comment tag for the language that the code sample is written in. For example, `#` for YAML and `//` for Ruby. |
| 21 | + |
| 22 | +To enable code sample annotations, you must specify a language followed by the word `annotate` after the starting triple backtick code tag. |
| 23 | + |
| 24 | +Within code sample annotations: |
| 25 | +- Annotations use single-line comment style and must start with a comment tag that matches the code language: `#`, `//`, `<!--`, `%%`. |
| 26 | +- Annotations apply to the code from the line below the comment tag to the next comment tag or the end of the code block. |
| 27 | +- Multiline-style comments, such as `/*` are not supported. |
| 28 | +- You can include any number of spaces before the comment tag starts. |
| 29 | +- You can include any number of spaces after the comment tag ends. |
| 30 | +- To create a blank annotation, insert a comment tag with no text after it. |
| 31 | +- Anything after the comment tag will be parsed with Markdown. Links, versioning, and other styling will render as if they were written in Markdown. |
| 32 | +- Multiple sequential comments will create a single annotation. |
| 33 | +- Lines that do not start with a comment tag and are empty or only contain spaces will be ignored. |
| 34 | +- You must start the code section with a single line comment. If the first line (or section) of the code does not need an annotation, you can use a comment tag with no text to create a blank annotation. |
| 35 | +- For HTML style, you can include a closing tag, `<!-- -->`, after your annotations to maintain syntax highlighting; this will not impact how the annotations render. |
| 36 | + |
| 37 | +## Writing code annotations |
| 38 | + |
| 39 | +Introduce the overall purpose of a code example with an introduction before the code block and use annotations to explain what specific lines of code do and why they do it. |
| 40 | + |
| 41 | +Prioritize clarity in code annotations while trying to keep them as short as possible. People use code samples as a foundation for their own work, so annotations should help people understand the sample as it is written and how they might adapt the sample for other uses. |
| 42 | + |
| 43 | +Consider your audience when writing code annotations and do not assume people will know why an example is written a certain way. |
| 44 | + |
| 45 | +Annotations can be used to show the expected outcomes for the code that they annotate, but the results for the entire code example should be in the introduction for the code example or discussed after the example, whichever way best serves the audience. |
| 46 | + |
| 47 | +If a code example is changed, check that all annotations are still valid. |
| 48 | + |
| 49 | +## Example of an annotated code example |
| 50 | + |
| 51 | + The following code example shows a workflow that posts a welcome comment on a pull request when it is opened. |
| 52 | + |
| 53 | + ```yaml annotate |
| 54 | + # The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. |
| 55 | + name: Post welcome comment |
| 56 | + # The `on` keyword lets you define the events that trigger when the workflow is run. |
| 57 | + on: |
| 58 | + # Add the `pull_request` event, so that the workflow runs automatically |
| 59 | + # every time a pull request is created. |
| 60 | + pull_request: |
| 61 | + types: [opened] |
| 62 | + # Modifies the default permissions granted to `GITHUB_TOKEN`. |
| 63 | + permissions: |
| 64 | + pull-requests: write |
| 65 | + # Defines a job with the ID `build` that is stored within the `jobs` key. |
| 66 | + jobs: |
| 67 | + build: |
| 68 | + name: Post welcome comment |
| 69 | + # Configures the operating system the job runs on. |
| 70 | + runs-on: ubuntu-latest |
| 71 | + # The `run` keyword tells the job to execute a command on the runner. |
| 72 | + steps: |
| 73 | + - run: gh pr comment $PR_URL --body "Welcome to the repository!" |
| 74 | + env: |
| 75 | + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
| 76 | + PR_URL: ${{ github.event.pull_request.html_url }} |
| 77 | + ``` |
0 commit comments