This guide summarizes the conventions enforced (and encouraged) for all Markdown and docs in this repository.
It complements CONTRIBUTING.md and the root .markdownlint.yml configuration.
- All Markdown must pass
markdownlint(locally via the pre-commit hook and in CI). - Disabled rule: MD013 (line length) – long lines allowed where readability (tables / URLs / command lines) benefits.
- Do not locally override rules unless absolutely necessary; prefer restructuring content.
- Use ATX (
#,##,###) style only. - Start at a single
#per file (title) and increment by one level; avoid skipping levels. - Surround each heading with exactly one blank line above and below.
- Avoid trailing punctuation (no final colon, period, or question mark) unless part of a proper noun.
- Ordered lists: use
1.for every item (markdownlint will auto-render numbers). - Unordered lists: use
-(not*or+). - Put a blank line before and after a list block (unless tightly bound to a parent list item sub-block).
- Indent nested list content by two spaces.
- Always use fenced blocks (backticks). Indented code blocks are not allowed.
- Supply a language hint whenever possible (
bash,python,lua,text,console). - Surround fenced blocks with one blank line before and after.
- For shell commands, omit the leading
$unless demonstrating interactive copy/paste prevention; if shown, also show output to satisfy MD014. - Use
textfor pseudo-code or command output with mixed content.
- Wrap bare URLs in angle brackets
<https://example.com>. - Use backticks for filenames, commands, CLI flags, environment variables, and literal code tokens.
- Prefer emphasis (
*italic*) sparingly; bold only for strong warnings or section callouts.
- Surround tables with one blank line above and below.
- Keep header separator row aligned but do not over-focus on spacing (lint does not require column width alignment).
- Use backticks for code-like cell content.
- No blank lines inside a single logical blockquote group.
- Each quoted paragraph or list line should start with
>. - Use blockquotes for external notices, important upstream references, or migration notes—not for styling.
- Long lines are acceptable (MD013 disabled). Do not hard-wrap paragraphs unless clarity significantly improves.
- Keep tables and link references on single lines when feasible.
- Use
ALL_CAPS.mdfor top-level meta-docs (README, LICENSE, CONTRIBUTING, INSTALL). - Place style / guide / topic-specific docs under
docs/. - Use descriptive filenames (e.g.
QUICKSTART.md,STYLE.md).
- Prefer imperative, concise wording ("Run the script" vs. "You should run").
- Avoid marketing language—be factual and actionable.
- Provide context before commands; describe what a block does if non-obvious.
| Pattern | Example |
|---|---|
| Command sequence | meson setup builddir && meson compile -C builddir |
| Config file snippet | setup = { 'devices': ('81:00.0',) } |
| Shell pipeline | echo \"test\" | socat - TCP4:localhost:22022 |
| Lua script | printf("Hello!\n") |
| Output capture | Pktgen Version: 25.08.0 |
- Link new end-user docs from the main
README.mdor an appropriate existing doc section. - Keep
QUICKSTART.mdfocused—avoid duplicating deep details already covered elsewhere. - When adding a new feature, include: purpose, quick example, limitations, and any performance considerations.
| Do | Avoid |
|---|---|
| Provide a runnable example for new features | Giant monolithic examples without explanation |
| Use consistent fenced code | Mixing indentation and fenced styles |
| Reference existing sections instead of duplicating content | Copy-pasting large README segments |
| Keep tables compact and scannable | Over-formatting table spacing |
| Add language hints to all code blocks | Leaving unlabeled fences |
Rare cases (generated content, pasted command output, license headers) may intentionally violate some guidelines—these should be minimal and explained in a comment or preceding sentence.
Questions or suggestions? Update this file or open an issue.