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.3.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…>.

11.3.2. Acronyms

Acronyms should generally be spelled out the first time they appear in a document, as in: Network Time Protocol (NTP). After the acronym has been defined, you should generally use the acronym only (not the whole term, unless it makes more sense contextually to use the whole term). Usually, acronyms are defined only one per document. But if you prefer, you can also define them the first time they appear in each chapter.

All acronyms should be enclosed in acronym tags, with a role attribute with the full term defined. This allows a link to the glossary to be created, and for mouseovers to be rendered with the fully expanded term.

11.3.3. Indentation

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

Opening tags increase the indentation level by 2 spaces. Closing tags decrease the indentation level by 2 spaces. Blocks of 8 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 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> ... </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.

Vim users might want to configure their editor with:

augroup sgmledit autocmd FileType sgml set formatoptions=cq2l " Special formatting options autocmd FileType sgml set textwidth=70 " Wrap lines at 70 columns autocmd FileType sgml set shiftwidth=2 " Automatically indent autocmd FileType sgml set softtabstop=2 " Tab key indents 2 spaces autocmd FileType sgml set tabstop=8 " Replace 8 spaces with a tab autocmd FileType sgml set autoindent " Automatic indentation augroup END

11.3.4. Tag Style

11.3.4.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 lang='en'> <articleinfo> <title>NIS</title> <pubdate>October 1999</pubdate> <abstract> <para>... ... ...</para> </abstract> </articleinfo> <sect1> <title>...</title> <para>...</para> </sect1> <sect1> <title>...</title> <para>...</para> </sect1> </article>

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

11.3.5. 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 documentation 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.

11.3.6. 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:

    FreeBSD&nbsp;4.7
  • between multiword names (use with caution when applying this to more than 3-4 word names like The FreeBSD Brazilian Portuguese Documentation Project):

    Sun&nbsp;Microsystems

This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/

For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.

For questions about this documentation, e-mail <doc@FreeBSD.org>.