Markdown Code Reviews

Style Guide

Developers should treat documentation like other source code and follow the same rules and checklists when reviewing documentation as code.

Documentation should both use good Markdown syntax to ensure it’s properly parsed, and follow good writing style guidelines to ensure the document is easy to read and understand.

Markdown

Markdown is a lightweight markup language that you can use to add formatting elements to plaintext text documents. Created by John Gruber in 2004, Markdown is now one of the world’s most popular markup languages.

Using Markdown is different from using a WYSIWYG editor. In an application like Microsoft Word, you click buttons to format words and phrases, and the changes are visible immediately. Markdown isn’t like that. When you create a Markdown-formatted file, you add Markdown syntax to the text to indicate which words and phrases should look different.

You can find more information and full documentation here.

Linters

Markdown has specific way of being formatted. It is important to respect this formatting, otherwise some interpreters which are strict won’t properly display the document. Linters are often used to help developers properly create documents by both verifying proper Markdown syntax, grammar and proper English language.

A good setup includes a markdown linter used during editing and PR build verification, and a grammar linter used while editing the document. The following are a list of linters that could be used in this setup.

markdownlint

markdownlint is a linter for markdown that verifies Markdown syntax, and also enforces rules that make the text more readable. Markdownlint-cli is an easy-to-use CLI based on Markdownlint.

It’s available as a ruby gem, an npm package, a Node.js CLI and a VS Code extension. The VS Code extension Prettier also catches all markdownlint errors.

Installing the Node.js CLI

npm install -g markdownlint-cli

Running markdownlint on a Node.js project

markdownlint **/*.md --ignore node_modules

Fixing errors automatically

markdownlint **/*.md --ignore node_modules --fix

A comprehensive list of markdownlint rules is available here.

write-good

write-good is a linter for English text that helps writing better documentation.

npm install -g write-good

Run write-good

write-good *.md

Run write-good without installing it

npx write-good *.md

Write Good is also available as an extension for VS Code

VS Code Extensions

Write Good Linter

The Write Good Linter Extension integrates with VS Code to give grammar and language advice while editing the document.

markdownlint extension

The markdownlint extension examines the Markdown documents, showing warnings for rule violations while editing.

Build Validation

Linting

To automate linting with markdownlint for PR validation in GitHub actions, you can either use linters aggregator as we do with MegaLinter in this repository or use the following YAML.

name: Markdownlint

on:
  push:
    paths:
      - "**/*.md"
  pull_request:
    paths:
      - "**/*.md"

jobs:
  lint:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js
      uses: actions/setup-node@v1
      with:
        node-version: 12.x
    - name: Run Markdownlint
      run: |
        npm i -g markdownlint-cli
        markdownlint "**/*.md" --ignore node_modules

Checking Links

To automate link check in your markdown files add markdown-link-check action to your validation pipeline:

  markdown-link-check:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - uses: gaurav-nelson/github-action-markdown-link-check@v1

More information about markdown-link-check action options can be found at markdown-link-check home page

Code Review Checklist

In addition to the Code Review Checklist you should also look for these documentation specific code review items

• Is the document easy to read and understand and does it follow good writing guidelines?
• Is there a single source of truth or is content repeated in more than one document?
• Is the documentation up to date with the code?
• Is the documentation technically, and ethically correct?

Writing Style Guidelines

The following are some examples of writing style guidelines.

Agree in your team which guidelines you should apply to your project documentation. Save your guidelines together with your documentation, so they are easy to refer back to.

Wording

• Use inclusive language, and avoid jargon and uncommon words. The docs should be easy to understand
• Be clear and concise, stick to the goal of the document
• Use active voice
• Spell check and grammar check the text
• Always follow chronological order
• Visit Plain English for tips on how to write documentation that is easy to understand.

Document Organization

• Organize documents by topic rather than type, this makes it easier to find the documentation
• Each folder should have a top-level README.md and any other documents within that folder should link directly or indirectly from that README.md
• Document names with more than one word should use underscores instead of spaces, for example machine_learning_pipeline_design.md. The same applies to images

Headings

• Start with a H1 (single # in markdown) and respect the order H1 > H2 > H3 etc
• Follow each heading with text before proceeding with the next heading
• Avoid putting numbers in headings. Numbers shift, and can create outdated titles
• Avoid using symbols and special characters in headers, this causes problems with anchor links
• Avoid links in headers

Links

• Avoid duplication of content, instead link to the single source of truth
• Link but don’t summarize. Summarizing content on another page leads to the content living in two places
• Use meaningful anchor texts, e.g. instead of writing Follow the instructions [here](/docs/code-reviews/recipes/markdown.html) write Follow the [Markdown guidelines](/docs/code-reviews/recipes/markdown.html)
• Make sure links to Microsoft docs do not contain the language marker /en-us/ or /fr-fr/, as this is automatically determined by the site itself.

Lists

• List items should start with capital letters if possible
• Use ordered lists when the items describe a sequence to follow, otherwise use unordered lists
• For ordered lists, prefix each item with 1. When rendered, the list items will appear with sequential numbering. This avoids number-gaps in list
• Do not add commas , or semicolons ; to the end of list items, and avoid periods . unless the list item represents a complete sentence

Images

• Place images in a separate directory named img
• Name images appropriately, avoiding generic names like screenshot.png
• Avoid adding large images or videos to source control, link to an external location instead

Emphasis and special sections

• Use bold or italic to emphasize

  For sections that everyone reading this document needs to be aware of, use blocks

• Use backticks for code, a single backtick for inline code like pip install flake8 and 3 backticks for code blocks followed by the language for syntax highlighting

  def add(num1: int, num2: int):
    return num1 + num2
  

• Use check boxes for task lists
  • Item 1
  • Item 2
  • Item 3
• Add a References section to the end of the document with links to external references

• Prefer tables to lists for comparisons and reports to make research and results more readable

  Option	Pros	Cons
  Option 1	Some pros	Some cons
  Option 2	Some pros	Some cons

General

• Always use Markdown syntax, don’t mix with HTML
• Make sure the extension of the files is .md - if the extension is missing, a linter might ignore the files