Style Guide for Markdown Writing
Last updated
Was this helpful?
Last updated
Was this helpful?
The .
Considers , and other extensions.
This project is community driven, and tries to reach consensus. Maintainers will only step in if the community cannot reach a decision. Discussion will take place .
A Chinese translation can be found at:
Are you notable? Send a pull request.
If you are a notable user:
you can opt to be contacted before any major changes happen to the standard. Please inform this on the pull request that adds you to the notable list.
your vote on decisions will have much greater weight
You are more likely to be notable if your project:
uses Markdown heavily. E.g.: Markdown engines, text editors, lots of markdown documentation, etc.
is popular. Any popularity measure will be taken into account, e.g. GitHub stars, Google Rank, etc. 2K+ GitHub stars makes for a very strong case.
Disputed points will be given multiple alternative style options.
Each feature and option will receive a lowercase hyphen separated identifier.
Each option will have a header of form:
The first option header that appears in this text is the default value.
E.g., if line wrapping had 3 alternatives, we could give it the key wrap, and for each alternative create a header:
When referring to this guide, specify all non-default options in a comma separated fashion:
readable
portable: produces the same output, or good output, across multiple implementations.
easy to write and modify later
diff friendly
easy to remember and implement on editors
provide rationale behind difficult choices.
Readability vs writability
Many design choices come down to:
do you want to write fast
or do you want people to read fast
There may be use cases in which either is preferred:
for source code, readability becomes more important, as programmers are going to open the files on their editors often.
Editor features like syntax highlighting and line wrapping can greatly reduce problems, but it is of course better if people don't need to change their editors at all.
for forums like Stack Overflow, people will very rarely read the source, only the rendered output. So it might be better to optimize writing speed.
The current style is inconsistent with either of those optimizations. For now, we propose two sets of options (profiles) which optimize either one: readability and writability profiles.
Readability profile
wrap:space
list-marker:asterisk
code:indented
Writability profile
wrap:no
list-marker:hyphen
code:fenced
When this style guide needs to represent multiple adjacent spaces, or spaces at the beginning or ending of code blocks, this will be mentioned explicitly in prose, and a dot will be used to make the space visible.
E.g.:
a, space, b:
a, 2 spaces, b:
space, ab:
ab, space:
File extension
Use .md.
Rationale: why not .mkd or .markdown?
shorter
more popular
does not have important conflicts
File name
Prefer to base the file name on the top-header level:
replace upper case letters with lower case
strip articles the, a, an from the start
replace punctuation and white space characters by hyphens
replace consecutive hyphens by a single hyphen
strip surrounding hyphens
Good:
Bad, multiple consecutive hyphens:
Bad, surrounding hyphens:
Rationale: why not underscore or camel case? Hyphens are the most popular URL separator today, and markdown files are most often used in contexts where:
there are hyphen separated HTML files in the same project, possibly the same directory as the markdown files.
filenames will be used directly on URLs. E.g.: GitHub blobs.
Newlines
Don't use 2 or more consecutive empty lines, that is, more than two consecutive newline characters, except where they must appear literally such as in code blocks.
End files with a newline character, and don't leave empty lines at the end of the file.
Don't use trailing whitespace unless it has a function such as indicating a line break.
Good:
list
list
Header
Good, code block:
Bad:
list
list
Rationale: multiple empty lines occupy more vertical screen space, and do not significantly improve readability.
Spaces after sentences
Option space-sentence:1
Use a single space after sentences.
Bad, 2 spaces:
Good:
Rationale: advantages over space-sentence:2:
easier to edit
usually not necessary if you use wrap:inner-sentence or wrap:sentence
space-sentence:2 gives a false sense of readability as it is ignored on the HTML output
more popular
Advantages of space-sentence:2:
easier to see where sentences end
Option space-sentence:2
Bad, single space:
Good:
Option wrap:inner-sentence
Try to keep lines under 80 characters by breaking large paragraphs logically at points such as:
sentences: after a period ., question ? or exclamation mark !
It is acceptable to have a line longer than 80 characters, but keep in mind that long sentences are less readable and look worse in tools such as git diff.
Set your editor to wrap lines visually for Markdown in case a large line is present.
Good:
Rationale:
Diffs look better, since a change to a clause shows up as a single diff line.
Occasional visual wrapping does not significantly reduce the readability of Markdown, since the only language feature that can be indented to indicate hierarchy are nested lists.
At some point GitHub translated single newlines to line breaks in READMEs, and still does so on comments. Currently there is no major engine which does it, so it is safe to use newlines.
Some tools are not well adapted for long lines, e.g. Vim and git diff will not wrap lines by default. This can be configured however via git config --global core.pager 'less -r' for Git and set wrap for Vim.
Downsides:
requires considerable writer effort, specially when modifying code.
Markdown does not look like the rendered output, in which there are no line breaks.
Manual line breaking can make the Markdown more readable than the rendered output, which is bad because it gives a false sense of readability encouraging less readable long paragraphs.
Breaks some email systems, which always break a line on a single newline, and make your email look something like this.
Option wrap:no
Don't wrap lines.
Rationale: very easy to edit. But diffs on huge lines are hard to read.
Option wrap:space
Always wrap at the end of the first word that exceeds 80 characters.
Rationale: source code becomes is very readable and text editors support it automatically. But diffs will look bad, and changing lines will be hard.
Option wrap:sentence
Rationale: similar advantages as wrap:inner-sentence, but easier for people to follow since the rule is simple: break after the period. But may produce long lines with hard to read diffs.
Dollar signs in shell code
Don't prefix shell code with dollar signs $ unless you will be showing the command output on the same code block.
If the goal is to clarify what the language is, do it on the preceding paragraph.
Rationale: harder to copy paste, noisier to read.
Good:
Bad:
Good, shows output:
Good, language specified on preceding paragraph:
What to mark as code
Use code blocks or inline code for:
executables. E.g.:
Differentiate between tool and the name of related projects. E.g.: gcc vs GCC.
file paths
version numbers
capitalized explanation of abbreviations:
other terms related to computers that you don't want to add to your dictionary
Don't mark as code:
names of projects. E.g.: GCC
names of libraries. E.g.: libc, glibc
Spelling and grammar
Use correct spelling and grammar.
Prefer writing in English, and in particular American English. Rationale: American English speakers have the largest GDP, specially in the computing industry.
Use markup like URL or code on words which you do not want to add to your dictionary so that spell checkers can ignore them automatically.
Beware of case sensitive spelling errors, in particular for project, brand names or abbreviations:
Good: URL, LinkedIn, DoS attack
Bad: url, Linkedin, dos attack
When in doubt, prefer the same abbreviation as used on Wikipedia.
Avoid informal contractions:
Good: biography, repository, directory
Bad: bio, repo, dir
Avoid line breaks, as they don't have generally accepted semantic meaning.
In the rare case you absolutely need them, end a lines with exactly two spaces.
Option header:atx
Bad:
Good:
Rationale: advantages over Setex:
easier to write because in Setex you have to match the number of characters in both lines for it to look good
works for all levels, while Setex only goes up to level 2
occupy only one screen line, while Setex occupies 2
Advantages of Setex
more visible. Not very important if you have syntax highlighting.
Include a single space between the # and the text of the header.
Bad:
Good:
Don't use the closing # character.
Bad:
Good:
Rationale: easier to maintain.
Don't add spaces before the number sign #.
Bad:
Good:
Option header:setex
Bad:
Good:
Don't skip header levels.
Bad:
Good:
Surround headers by a single empty line except at the beginning of the file.
Bad:
Good:
Bad:
Good:
Avoid using two headers with the same content in the same markdown file.
Rationale: many markdown engines generate IDs for headers based on the header content.
Bad:
Good:
Top-level header
If you target HTML output, write your documents so that it will have one and only one h1 element as the first thing in it that serves as the title of the document. This is the HTML top-level header.
How this h1 is produced may vary depending on your exact technology stack: some stacks may generate it from metadata, for example Jekyll through the front-matter.
Storing the top-level header as metadata has the advantage that it can be reused elsewhere more easily, e.g. on a global index, but the downside of lower portability.
If your target stack does not generate the top-level header in another way, include it in your markdown file. E.g., GitHub.
Top-level headers on index-like files such as README.md or index.md should serve as a title for their parent directory.
Downsides of top-level headers:
take up one header level. This means that there are only 5 header levels left, and each new header will have one extra #, which looks worse and is harder to write.
duplicate filename information, which most often can already be seen on a URL. In most cases, the filename can be trivially converted to a top-level, e.g.: some-filename.md to Some filename.
Advantages of top-level headers:
more readable than URL's, especially for non-technically inclined users.
Header case
Use an upper case letter as the first letter of a header, unless it is a word that always starts with lowercase letters, e.g. computer code.
Good:
Good, computer code that always starts with lower case:
Bad:
The other letters have the same case they would have in the middle of a sentence.
Good:
Bad:
End of a header
Indicate the end of a header's content that is not followed by a new header by an horizontal rule:
Header length
Keep headers as short as possible.
Instead of using a huge sentence, make the header a summary to the huge sentence, and write the huge sentence as the first paragraph beneath the header.
Rationale: if automatic IDs are generated by the implementation, it is:
easier to refer to the header later while editing
less likely that the IDs will break due to rephrasing
easier to distinguish between different IDs
Good:
Bad:
Punctuation at the end of headers
Don't add a trailing colon : to headers.
Rationale: every header is an introduction to what is about to come next, which is exactly the function of the colon.
Don't add a trailing period . to headers.
Rationale: every header consists of a single short sentence, so there is not need to add a sentence separator to it.
Good:
Bad:
Bad:
Header synonyms
Headers serve as an index for users searching for keywords.
For this reason, you may want to give multiple keyword possibilities for a given header.
To do so, simply create a synonym header with empty content just before its main header.
E.g.:
Every empty header with the same level as the following one is assumed to be a synonym. This is not the case if levels are different:
Follow the greater than marker > by one space.
Good:
a
Bad:
a
Bad, 2 spaces:
a
Use a greater than sign for every line, including wrapped.
Bad:
Long line that was wrapped.
Good:
Long line that was wrapped.
Don't use empty lines inside a single block quote.
Good:
a
b
Bad:
a
b
Marker
Unordered
Option list-marker:hyphen
Use the hyphen marker.
Good:
a
b
Bad:
a
b
a
b
Rationale:
asterisk * can be confused with bold or italic markers.
plus sign + is not popular
Downsides:
* and + are more visible. * is more visible
Option list-marker:asterisk
Use *.
Option list-marker:plus
Use +.
Ordered
Prefer lists only with the marker 1. for ordered lists, unless you intend to refer to items by their number in the same markdown file or externally.
Prefer unordered lists unless you intent to refer to items by their number.
Best, we will never refer to the items of this list by their number:
a
c
b
Better, only 1.:
a
c
b
Worse, we will never refer to the items of this list by their number:
a
c
b
Acceptable, refer to them in the text:
Acceptable, meant to be referred by number from outside of the markdown file:
Rationale:
If you want to change a list item in the middle of the list, you don't have to modify all items that follow it.
Diffs will show only the significant line which was modified.
Content stays aligned without extra effort if the numbers reach 2 digits. E.g.: the following is not aligned:
a
b
References break when a new list item is added. To reduce this problem:
keep references close to the list so authors are less likely to forget to update them
when referring from an external document, always refer to an specific version of the markdown file
Spaces before list marker
Do not add any space before list markers, except to obey the current level of indentation.
Bad:
a
b
Good:
a
b
Good, c is just following the indentation of b:
a
b
c
Bad, c modified the indentation of b:
a
b
c
Rationale:
easier to type
easier to reason about levels
Spaces after list marker
Option list-space:mixed
If the content of every item of the list is fits in a single paragraph, use 1 space.
Otherwise, for every item of the list:
use 3 spaces for unordered lists.
use 2 spaces for ordered lists. One less than for unordered because the marker is 2 chars long.
Bad, every item is one line long:
a
b
Good:
a
b
Bad, every item is one line long:
a
b
Good:
a
b
Bad: item is longer than one line:
item that is wrapped
item 2
Good:
item that is wrapped
item 2
Bad: item is longer than one line:
a
par
b
Good:
a
par
b
Option list-space:1
Always add one space to the list marker.
Bad, 3 spaces:
a
b
c
Good:
a
b
c
Bad, 2 spaces:
a
b
c
Good:
a
b
c
Rationale: list-space mixed vs 1
The advantages of list-space:1 are that
it removes the decision of how many spaces you should put after the list marker: it is always one.
We could choose to always have list content indented as:
a
b
but that is ugly.
You never need to change the indentation of the entire list because of a new item.
This may happen in list-space:mixed if you have:
a
b
and will add a multi-line item:
a
b
c
d
Note how a and b were changed because of c.
The disadvantages of list-space:1
creates three indentation levels for the language:
4 for indented code blocks
3 for ordered lists
2 for unordered lists
That means that you cannot easily configure your editor indent level to deal with all cases when you want to change the indentation level of multiple list item lines.
Is not implemented consistently across editors.
In particular what should happen at:
a
This (2 spaces):
Or no spaces:
Likely the original markdown said no spaces:
To put a code block within a list item, the code block needs to be indented twice — 8 spaces or two tabs
But many implementations did otherwise.
Indentation of content inside lists
The indentation level of what comes inside list and of further list items must be the same as the first list item.
Bad:
item that is wrapped
item 2
Good:
item that is wrapped
item 2
Bad:
item 1
Content 1
item 2
Content 2
Good (if it matches your spaces after list marker style):
item 1
Content 1
item 2
Content 2
Bad:
item 1
Content 1
item 2
Content 2
Good (if it matches your spaces after list marker style):
item 1
Content 1
item 2
Content 2
code
a
Empty lines inside lists
If every item of a list is a single line long, don't add empty lines between items. Otherwise, add empty lines between every item.
Bad, single lines:
item 1
item 2
item 3
Good:
item 1
item 2
item 3
Bad, multiple lines:
item that
is wrapped
item 2
item 3
Good:
item that is wrapped
item 2
item 3
Bad, multiple lines:
item 1
Paragraph.
item 2
item 3
Good:
item 1.
Paragraph.
item 2
item 3
Bad, multiple lines:
item 1
item 11
item 12
item 13
item 2
item 3
Good:
item 1
item 11
item 12
item 13
item 2
item 3
Rationale: it is hard to tell where multi-line list items start and end without empty lines.
Empty lines around lists
Surround lists by one empty line.
Bad:
Good:
Case of first letter of list item
Each list item has the same case as it would have if it were concatenated with the sentence that comes before the list.
Good:
because it could be replaced with:
Good:
because it could be replaced with:
Good:
because it could be replaced with:
Punctuation at the end of list items
Punctuate at the end of list items if either it:
contains multiple sentences or paragraphs
starts with an upper case letter
Otherwise, omit the punctuation if it would be a period.
Bad, single sentences:
apple.
banana.
orange.
Good:
apple
banana
orange
Idem:
go to the market
then buy some fruit
finally eat the fruit
Good, not terminated by period but by other punctuation.
go to the marked
then buy fruit?
of course!
Bad, multiple sentences:
go to the market
then buy some fruit. Bad for wallet
finally eat the fruit. Good for tummy
Good:
go to the market
then buy some fruit. Bad for wallet.
finally eat the fruit. Good for tummy.
Note: nothing forbids one list item from ending in period while another in the same list does not.
Bad, multiple paragraphs:
go to the market
then buy some fruit
Bad for wallet
finally eat the fruit
Good for tummy
Good:
go to the market
then buy some fruit.
Bad for wallet.
finally eat the fruit.
Good for tummy.
Bad, starts with upper case:
Go to the market
Then buy some fruit
Finally eat the fruit
Good:
Go to the market.
Then buy some fruit.
Finally eat the fruit.
Avoid the definition list extension since it is not present in many implementations nor in CommonMark.
Instead, use either:
formated lists:
format the item be defined as either of bold, link or code
separate the item from the definition with a colon and a space :.
don't align definitions as it is harder to maintain and does not show on the HTML output
Good:
apple: red fruit
dog: noisy animal
Good:
apple: red fruit.
Very tasty.
dog: noisy animal.
Not tasty.
Good:
Good:
-f: force
-r: recursive
Bad, no colon:
apple red fruit
dog noisy animal
Bad, space between term and colon:
apple : red fruit
dog : noisy animal
Bad, definitions aligned:
apple: red fruit
dog: noisy animal
headers.
Good:
Option code:fenced
Only use fenced code blocks.
Comparison to indented code blocks:
disadvantage: not part of the original markdown, thus less portable, but added to CommonMark.
advantage: many implementations, including GitHub's, allow to specify the code language with it
Don't indent fenced code blocks.
Always specify the language of the code is applicable.
Good:
Bad:
Option code:indented
Only use indented code blocks.
Indent indented code blocks with 4 spaces.
Code blocks must be surrounded by one empty line.
Prefer to end the phrase before a code block with a colon :.
Good:
Bad, no colon
Rationale:
headers are better section separators since they say what a section is about.
horizontal rules don't have a generally accepted semantic meaning. This guide gives them one.
Use 3 hyphens without spaces:
Extension.
Surround tables by one empty line.
Don't indent tables.
Surround every line of the table by pipes.
Align all border pipes vertically.
Separate header from body by hyphens except at the aligned pipes |.
Pipes | must be surrounded by a space, except for outer pipes which only get one space internally, and pipes of the hyphen separator line.
Column width is determined by the longest cell in the column.
Good table:
Rationale:
unaligned tables tables are easier to write, but aligned tables are more readable, and people read code much more often than they edit it.
preceding pipes make it easier to determine where a table starts and ends. Trailing pipes make it look better because of symmetry.
why no spaces around pipes of the hyphen separator line, i.e.: |---| instead of | - |? No spaces looks better, works on GitHub. Downside: harder to implement automatic alignment in editors, as it requires a special rule for the separator line.
Separate consecutive:
lists
indented code blocks
blockquotes
list followed by external code block
with an empty HTML comment <!-- -->.
list 1
list 1
list 2
list 2
blockquote 1 blockquote 1
blockquote 2 blockquote 2
list
list
code outside list code outside list
Don't use inner spaces.
Good:
Bad:
For inline code in which the space is crucial:
explain in writing that the spaces must be there
add something after the space if possible
Good:
Rationale: most browsers don't render the surrounding spaces nor add them to the clipboard on copy.
Reference-style links
Links:
use the trailing [] on implicit links.
Good:
Bad:
Rationale: while omitting [] works on most major implementations, it is not specified in the documentation not implemented in the original markdown.
Definitions:
must be the last thing on the file
must be sorted alphabetically by the ID
don't enclose URLs by angle brackets
align URLs and link names as in a table
link IDs use only lowercase letters. Rationale: they are case insensitive,
lowercase only is easier to write, and the readability gain of mixed case is not very big.
Good:
Bad, not ordered by id:
Bad, not aligned:
Single or double quote titles
Use double quotes, not single quotes.
Rationale: single quotes do not work in all major implementations, double quotes do.
Bold
Use double asterisk format: **bold**.
Rationale: more common and readable than the double underline __bold__ form.
Italic
Use single asterisk format: *italic*.
Rationale:
more common and readable than the underscore form
consistent with the bold format, which also uses asterisks
Uppercase for emphasis
Don't use uppercase for emphasis: use emphasis constructs like bold or italic instead.
Rationale: CSS has text-transform:uppercase which can easily achieve the same effect consistently across the entire website if you really want uppercase letters.
Emphasis vs headers
Don't use emphasis elements (bold or italics) to introduce a multi line named section: use headers instead.
Rationale: that is exactly the semantic meaning of headers, and not necessarily that of emphasis elements. As a consequence, many implementations add useful behaviors to headers and not to emphasis elements, such as automatic id to make it easier to refer to the header later on.
Good:
Bad:
Automatic links without angle brackets
Don't use automatic links without angle brackets.
Good:
Bad:
Rationale: it is an extension, <> is easy to type and saner.
If you want literal links which are not autolinks, enclose them in code blocks. E.g.:
Rationale: many tools automatically interpret any word starting with https as a link.
Content of automatic links
All automatic links must start with the string https.
In particular, don't use relative automatic links. Use bracket links instead for that purpose.
Good:
Bad:
Good:
Bad:
Rationale: it is hard to differentiate automatic links from HTML tags. What if you want a relative link to a file called script?
Email automatic links
Don't use email autolinks <address@example.com>. Use raw HTML instead.
Rationale: the original markdown specification states it:
"performs a bit of randomized decimal and hex entity-encoding to help obscure your address from address-harvesting spambots".
Therefore, the output is random, ugly, and as the spec itself mentions:
but an address published in this way will probably eventually start receiving spam
Portability tests are carried out with the .
by Google.
. This guide was originally forked from it. It has been extended considerably, some decisions were modified, and no original lines remain.
by Miguel de Icaza (GNOME, Mono). Short.
Asked on Stack Exchange:
. Documentation has some links back to this style:
: after words like and, which, if ... then, commas ,
large
Requires users of programming text editors like Vim, which are usually configured to not wrap, to toggle visual wrapping on. This can be automated, but
Notable occurrence: .
As an exception, may be optionally used for the . Use this exception sparingly, in cases where typographical perfection is important, e.g.: README of a project.
Rationale: why not for all headers? It requires too much effort to decide if edge-case words should be upper case or not.
CommonMark .
Avoid starting a list item directly with indented code blocks because that is not consistently implemented. a single space is assumed in that case:
: red fruit
: red fruit
Don't use horizontal rules except to indicate the .
there exist tools which help keeping the table aligned. For example, Vim has the which allows to align the entire table with :Tabular /|.