All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.
Chapter 11. Writing Style
Table of Contents
11.1. Tips
Technical documentation can be improved by consistent use of several principles. Most of these can be classified into three goals: be clear, be complete, and be concise. These goals can conflict with each other. Good writing consists of a balance between them.
11.1.1. Be Clear
Clarity is extremely important. The reader may be a novice, or reading the document in a second language. Strive for simple, uncomplicated text that clearly explains the concepts.
Avoid flowery or embellished speech, jokes, or colloquial expressions. Write as simply and clearly as possible. Simple text is easier to understand and translate.
Keep explanations as short, simple, and clear as possible. Avoid empty phrases like "in order to", which usually just means "to". Avoid potentially patronizing words like "basically". Avoid Latin terms like "i.e.," or "cf.", which may be unknown outside of academic or scientific groups.
Write in a formal style. Avoid addressing the reader as "you". For example, say "copy the file to /tmp" rather than "you can copy the file to /tmp".
Give clear, correct, tested examples. A trivial example is better than no example. A good example is better yet. Do not give bad examples, identifiable by apologies or sentences like "but really it should never be done that way". Bad examples are worse than no examples. Give good examples, because even when warned not to use the example as shown, the reader will usually just use the example as shown.
Avoid weasel words like "should", "might", "try", or "could". These words imply that the speaker is unsure of the facts, and create doubt in the reader.
Similarly, give instructions as imperative commands: not "you should do this", but merely "do this".
11.1.2. Be Complete
Do not make assumptions about the reader’s abilities or skill level. Tell them what they need to know. Give links to other documents to provide background information without having to recreate it. Put yourself in the reader’s place, anticipate the questions they will ask, and answer them.
11.1.3. Be Concise
While features should be documented completely, sometimes there is so much information that the reader cannot easily find the specific detail needed. The balance between being complete and being concise is a challenge. One approach is to have an introduction, then a "quick start" section that describes the most common situation, followed by an in-depth reference section.
11.2. Guidelines
To promote consistency between the myriad authors of the FreeBSD documentation, some guidelines have been drawn up for authors to follow.
- Use American English Spelling
There are several variants of English, with different spellings for the same word. Where spellings differ, use the American English variant. "color", not "colour", "rationalize", not "rationalise", and so on.
The use of British English may be accepted in the case of a contributed article, however the spelling must be consistent within the whole document. The other documents such as books, web site, manual pages, etc. must use American English.
- Do not use contractions
Do not use contractions. Always spell the phrase out in full. "Don’t use contractions" is wrong.
Avoiding contractions makes for a more formal tone, is more precise, and is slightly easier for translators.
- Use the serial comma
In a list of items within a paragraph, separate each item from the others with a comma. Separate the last item from the others with a comma and the word "and".
For example:
This is a list of one, two and three items.
Is this a list of three items, "one", "two", and "three", or a list of two items, "one" and "two and three"?
It is better to be explicit and include a serial comma:
This is a list of one, two, and three items.
- Avoid redundant phrases
Do not use redundant phrases. In particular, "the command", "the file", and "man command" are often redundant.
For example, commands:
Wrong: Use the
gitcommand to update sources.Right: Use
gitto update sources.Filenames:
Wrong: … in the filename /etc/rc.local…
Right: … in /etc/rc.local…
Manual page references (the second example uses
citerefentrywith the csh(1) entity):Wrong: See
man cshfor more information.Right: See csh(1).
For more information about writing style, see Elements of Style by William Strunk.
11.3. Style Guide
To keep the source for the documentation consistent when many different people are editing it, please follow these style conventions.
11.4. One sentence per line
Use Semantic Line Breaks in the documentation, a technique called "one sentence per line". The idea of this technique is to help the users to write and read documentation. To get more information about this technique read the Semantic Line Breaks page.
This is an example which does not use "one sentence per line".
And this is an example which uses the technique.
All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.
11.5. Acronyms
Acronyms should be defined the first time they appear in a document, as in: "Network Time Protocol (NTP)". After the acronym has been defined, use the acronym alone unless it makes more sense contextually to use the whole term. Acronyms are usually defined only once per chapter or per document.
All acronyms should be enclosed using the ` character.
11.6. Special Character List
This list of special characters shows the correct syntax and the output when used in FreeBSD documentation. If a character is not on this list, ask about it on the FreeBSD documentation project mailing list.
| Name | Syntax | Rendered |
|---|---|---|
Copyright | (C) | © |
Registered | (R) | ® |
Trademark | (TM) | ™ |
Em dash | -- | — |
Ellipses | ... | … |
Single right arrow | -> | → |
Double right arrow | => | ⇒ |
Single left arrow | <- | ← |
Double left arrow | <= | ⇐ |
11.7. Linting with Vale
To maintain clarity and consistency across all documentation and website pages, Vale styles have been introduced in the documentation tree. Vale is a powerful linter for writing customized rules and can be used in multiple scenarios. Currently Vale can be used as a command line tool, for CI/CD pipelines, and integrated into an editor of choice.
The following table describes the current rule names and their respective severity.
| Name | Severity |
|---|---|
FreeBSD.BrandTerms | error |
FreeBSD.ConsciousLanguage | warning |
FreeBSD.Contractions | suggestion |
FreeBSD.EOLSpacing | warning |
FreeBSD.Hang | warning |
FreeBSD.Hyphens | warning |
FreeBSD.Spacing | error |
FreeBSD.SuperfluousOptArgInLinks | suggestion |
Vale.Avoid | error |
Vale.Repetition | error |
Vale.Spelling | error |
Vale.Terms | error |
11.7.1. Current Vale Rules
FreeBSD.BrandTerms: According to the copyright rules of The FreeBSD Foundation, freebsd should be written as FreeBSD. Similarly, every major vendor and company has specific rules on writing their brand names and trademarks. Care should be taken to be respectful to the brand value of others and to take time to write PostgreSQL, Node.js, Let’s Encrypt etc. Missing brand names should be added to the .vale/styles/FreeBSD/BrandTerms.yml in the
docrepository.FreeBSD.ConsciousLanguage: This rule proposes use of conscious language so that sensitive words pointing to the color, age, race, or sexual orientation of people are avoided where possible.
FreeBSD.Contractions: Contracted words should not be used. This rule avoids all contractions and suggests full words.
FreeBSD.EOLSpacing: In most of the documents EOL spacing is present which is not the desirable situation.
FreeBSD.Hang:
Hangis often used to mean that the application has stopped responding. This rule proposes better wording.FreeBSD.Hyphens: Often adverbs ending with 'ly' are added with a hyphen which is wrong.
FreeBSD.Spacing: Often double spaces are hard to catch with the naked eye and this is addressed here.
FreeBSD.SuperfluousOptArgInLinks: Suggest to empty square brackets in
link:macros when the displayed text coincides with the URL.Vale.Avoid: Enforces the DO NOT USE vocabulary terms for The FreeBSD Project. If any word is found that should not be in the documentation, the word should be added to .vale/styles/Vocab/Terms/reject.txt in the
docrepository. The list is empty at the moment.Vale.Repetition: Same words are often typed twice when leaving the keyboard and rejoining the work again. This rule finds repeated words and warns the users.
Vale.Spelling: At the moment there is a mix of en_US and en_GB spellings in the documentation and website. Vale comes with an in built dictionary from which uses strictly en_US and do not accept the en_GB variant of any words.
Vale.Terms: Enforces the PREFERRED vocabulary terms for The FreeBSD Project. At the moment the list of terms is empty and the FreeBSD specific terms will be added gradually. If any word is found to be correct and not available in the dictionary the word should be added to the .vale/styles/Vocab/Terms/accept.txt in the
docrepository.
More rules will be introduced in the upcoming days when and where required.
11.7.2. Using Vale
Vale can be used from the command line and from within an editor or IDE. textproc/vale can be installed as following:
$ pkg install vale11.7.2.1. Using Vale on the command line
Assuming that the doc repository was cloned into ~/doc the following commands are required to run:
% cd ~/doc
% vale .Vale is a CPU and memory intensive program due to the nature of the application and can take a while to show any output on the screen.
A better way to run the application is on specific folders or files rather than the entire |
11.7.2.2. Using Vale in editors
Vale works with major mainstream editors like editors/vim, editors/emacs, editors/vscode. At the moment the necessary configuration for editors/vim is described in Vim. A configuration for editors/emacs is being worked on.
Last modified on: May 11, 2023 by Ceri Davies