Markdown Code Reviews
CSE developers 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 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.
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.
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.
proselint is a command line utility that lints the text contents of the document. It checks for jargon, spelling errors, redundancy, corporate speak and other language related issues.
pip install proselint npm install -g proselint
write-good is a linter for English text that helps writing better documentation.
npm install -g write-good
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
Write Good Linter Extension integrates with VS Code to give grammar and language advice while editing the document.
markdownlint extension examines the Markdown documents, showing warnings for rule violations while editing.
To automate linting with
markdownlint for PR validation in GitHub actions as we do in this repo, 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
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.
- 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.
- 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
- 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
- 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](../recipes/Markdown.md)write
Follow the [Markdown guidelines](../recipes/Markdown.md)
- Make sure links to Microsoft docs (like
https://docs.microsoft.com/something/somethingelse) do not contain the language marker
/fr-fr/, as this is automatically determined by the site itself.
- 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
;to the end of list items, and avoid periods
.unless the list item represents a complete sentence
- Place images in a separate directory named
- Name images appropriately, avoiding generic names like
- 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
backticksfor code, a single backtick for inline code like
pip install flake8and 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
- 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