FreeBSD Documentation Project Primer for New Contributors
Prev		Next

Chapter 10. Writing style

Table of Contents
101
10.1. Style guide

In order to promote consistency between the myriad authors of the FreeBSD documentation, some guidelines have been drawn up for authors to follow.

Do not use contractions

Do not use contractions. Always spell the phrase out in full. ``Don't use contractions'' would be 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. Seperate the last item from the others with a comma and the word ``and''.

For example, look at the following:

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

Try not to use redundant phrases. In particular, ``the command'', ``the file'', and ``man command'' are probably redundant.

These two examples show this for commands. The second example is preferred.

Use the command cvsup to update your sources

Use cvsup to update your sources

These two examples show this for filenames. The second example is preferred.

... in the filename /etc/rc.local...

... in /etc/rc.local...

These two examples show this for manual references. The second example is preferred (the second example uses <citerefentry>).

See man csh for more information.

See csh(1)

Two spaces at the end of sentences

Always use two spaces at the end of sentences, as this improves readability, and eases use of tools such as emacs.

While it may be argued that a capital letter following a period denotes a new sentence, this is not the case, especially in name usage. ``Jordan K. Hubbard'' is a good example; it has a capital H following a period and a space, and there certainly isn't a new sentence there.

For more information about writing style, see Elements of Style, by William Strunk.

10.1. Style guide

To keep the source for the Handbook consistent when many different people are editing it, please follow these style conventions.

10.1.1. 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...>.

10.1.2. Indentation

Each file starts with indentation set at column 0, regardless of the indentation level of the file which might contain this one.

Every start tag increases the indentation level by 2 spaces, and every end tag decreases the indentation level by 2 spaces. 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 something like:

    +--- This is column 0
    V
    <chapter>
      <title>...</title>
    
      <sect1>
        <title>...</title>
    
        <sect2>
          <title>Indentation</title>
    
          <para>Each file starts with indentation set at column 0,
            <emphasis>regardless</emphasis> of the indentation level of the file
            which might contain this one.</para>
    
          <para>Every start tag increases the indentation level by 2 spaces, and
            every end tag decreases the indentation level by 2 spaces.  Content
            within elements should be indented by two spaces if the content runs
            over more than one line.</para>
    
          ...   
        </sect2>
      </sect1>
    </chapter>

If you use Emacs or Xemacs to edit the files then sgml-mode should be loaded automatically, and the Emacs local variables at the bottom of each file should enforce these styles.

10.1.3. Tag style

10.1.3.1. 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>
      <artheader>
        <title>NIS</title>
    
        <pubdate>October 1999</pubdata>
    
        <abstract>
          <para>...
        ...
        ...</para>
        </abstract>
      </artheader>
    
      <sect1>
        <title>...</title>
    
        <para>...</para>
      </sect1>
    
      <sect1>
        <title>...</title>
    
        <para>...</para>
      </sect1>
    </article>

10.1.3.2. Separating tags

Tags like <itemizedlist> which will always have further tags inside them, and in fact don't take character data themselves, are always on a line by themselves.

Tags like <para> and <term> don't 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.

10.1.4. White space changes

When committing changes, do not commit changes to the content at the same time as changes to the formatting.

This is so that the teams that convert the Handbook to other languages can quickly see what content has actually changed in your commit, without having to decide whether a line has changed because of the content, or just because it has been refilled.

For example, if you have added two sentences to a paragraph, such that the line lengths on the paragraph now go over 80 columns, first commit your change with the too-long line lengths. Then fix the line wrapping, and commit this second change. In the commit message for the second change, be sure to indicate that this is a whitespace-only change, and that the translation team can ignore it.

Prev	Home	Next
Translations		Using `sgml-mode` with Emacs