Writing Style 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. 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. 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. 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. Guidelines To promote consistency between the myriad authors of the &os; 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. will have to 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 svn command to update sources. Right: Use svn to update sources. Filenames: Wrong: … in the filename /etc/rc.local… Right: … in /etc/rc.local… Manual page references (the second example uses citerefentry with the &man.csh.1; entity):. Wrong: See man csh for more information. Right: See &man.csh.1;. Two spaces between sentences Always use two spaces between sentences, as it improves readability and eases use of tools such as Emacs. A period and spaces followed by a capital letter does not always mark a new sentence, especially in names. Jordan K. Hubbard is a good example. It has a capital H following a period and a space, and is certainly not a new sentence. For more information about writing style, see Elements of Style, by William Strunk. Style Guide To keep the source for the documentation consistent when many different people are editing it, please follow these style conventions. Letter Case Tags are entered in lower case, para, not PARA. Text that appears in SGML contexts is generally written in upper case, <!ENTITY…>, and <!DOCTYPE…>, not <!entity…> and <!doctype…>. 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 in acronym tags. Indentation The first line in each file starts with no indentation, regardless of the indentation level of the file which might contain the current file. Opening tags increase the indentation level by two spaces. Closing tags decrease the indentation level by two spaces. Blocks of eight spaces at the start of a line should be replaced with a tab. Do not use spaces in front of tabs, and do not add extraneous whitespace at the end of a line. Content within elements should be indented by two spaces if the content runs over more than one line. For example, the source for this section looks like this: chapter title...title sect1 title...title sect2 titleIndentationtitle paraThe first line in each file starts with no indentation, emphasisregardlessemphasis of the indentation level of the file which might contain the current file.para ... sect2 sect1 chapter Tags containing long attributes follow the same rules. Following the indentation rules in this case helps editors and writers see which content is inside the tags: paraSee the link linkend="gmirror-troubleshooting"Troubleshootinglink section if there are problems booting. Powering down and disconnecting the original filenameada0filename disk will allow it to be kept as an offline backup.para paraIt is also possible to journal the boot disk of a &os; system. Refer to the article link xlink:href="&url.articles.gjournal-desktop;"Implementing UFS Journaling on a Desktop PClink for detailed instructions.para When an element is too long to fit on the remainder of a line without wrapping, moving the start tag to the next line can make the source easier to read. In this example, the systemitem element has been moved to the next line to avoid wrapping and indenting: paraWith file flags, even systemitem class="username"rootsystemitem can be prevented from removing or altering files.para Configurations to help various text editors conform to these guidelines can be found in . Tag Style Tag Spacing Tags that start at the same indent as a previous tag should be separated by a blank line, and those that are not at the same indent as a previous tag should not: article lang='en' articleinfo titleNIStitle pubdateOctober 1999pubdate abstract para... ... ...para abstract articleinfo sect1 title...title para...para sect1 sect1 title...title para...para sect1 article Separating Tags Tags like itemizedlist which will always have further tags inside them, and in fact do not take character data themselves, are always on a line by themselves. Tags like para and term do not need other tags to contain normal character data, and their contents begin immediately after the tag, on the same line. The same applies to when these two types of tags close. This leads to an obvious problem when mixing these tags. When a starting tag which cannot contain character data directly follows a tag of the type that requires other tags within it to use character data, they are on separate lines. The second tag should be properly indented. When a tag which can contain character data closes directly after a tag which cannot contain character data closes, they co-exist on the same line. Whitespace Changes Do not commit changes to content at the same time as changes to formatting. When content and whitespace changes are kept separate, translation teams can easily see whether a change was content that must be translated or only whitespace. For example, if two sentences have been added to a paragraph so that the line lengths now go over 80 columns, first commit the change with the too-long lines. Then fix the line wrapping, and commit this second change. In the commit message for the second change, indicate that this is a whitespace-only change that can be ignored by translators. Non-Breaking Space Avoid line breaks in places where they look ugly or make it difficult to follow a sentence. Line breaks depend on the width of the chosen output medium. In particular, viewing the HTML documentation with a text browser can lead to badly formatted paragraphs like the next one: Data capacity ranges from 40 MB to 15 GB. Hardware compression … The general entity &nbsp; prohibits line breaks between parts belonging together. Use non-breaking spaces in the following places: between numbers and units: 57600&nbsp;bps between program names and version numbers: &os;&nbsp;9.2 between multiword names (use with caution when applying this to more than 3-4 word names like The &os; Brazilian Portuguese Documentation Project): Word List This list of words shows the correct spelling and capitalization when used in &os; documentation. If a word is not on this list, ask about it on the &a.doc;. Word XML Code Notes CD-ROM acronymCD-ROMacronym DoS (Denial of Service) acronymDoSacronym email file system IPsec Internet manual page mail server name server Ports Collection read-only Soft Updates stdin varnamestdinvarname stdout varnamestdoutvarname stderr varnamestderrvarname Subversion applicationSubversionapplication Do not refer to the Subversion application as SVN in upper case. To refer to the command, use commandsvncommand. &unix; &unix; userland things that apply to user space, not the kernel web server