aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml
blob: 873cf7cafacc59de3b4d3c4743ab0fbd8cb99446 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
<!-- Copyright (c) 1998 Nik Clayton, All rights reserved.

     Redistribution and use in source (SGML DocBook) and 'compiled' forms
     (SGML HTML, PDF, PostScript, RTF and so forth) with or without
     modification, are permitted provided that the following conditions
     are met:

      1. Redistributions of source code (SGML DocBook) must retain the above
         copyright notice, this list of conditions and the following
         disclaimer as the first lines of this file unmodified.

      2. Redistributions in compiled form (transformed to other DTDs,
         converted to PDF, PostScript, RTF and other formats) must reproduce
         the above copyright notice, this list of conditions and the
         following disclaimer in the documentation and/or other materials
         provided with the distribution.

     THIS DOCUMENTATION IS PROVIDED BY NIK CLAYTON "AS IS" AND ANY EXPRESS OR
     IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
     OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
     DISCLAIMED. IN NO EVENT SHALL NIK CLAYTON BE LIABLE FOR ANY DIRECT,
     INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
     (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
     SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
     HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
     STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
     ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE
     POSSIBILITY OF SUCH DAMAGE.

     $FreeBSD$
-->

<chapter id="writing-style">
  <title>Writing style</title>
  
  <para>In order to promote consistency between the myriad authors of the
    FreeBSD documentation, some guidelines have been drawn up for authors to
    follow.</para>
  
  <variablelist>
    <varlistentry>
      <term>Use American English spelling</term>

      <listitem>
	<para>There are several variants of English, with different spellings
	  for the same word.  Where spellings differ, use the American English
	  variant. <quote>color</quote>, not <quote>colour</quote>,
	  <quote>rationalize</quote>, not <quote>rationalise</quote>, and so
	  on.</para>

	<note>
	  <para>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.</para>
	</note>
      </listitem>
    </varlistentry>

    <varlistentry>
      <term>Do not use contractions</term>
      
      <listitem>
	<para>Do not use contractions.  Always spell the phrase out in full.
	  <quote>Don't use contractions</quote> would be wrong.</para>

	<para>Avoiding contractions makes for a more formal tone, is more
	  precise, and is slightly easier for translators.</para>
      </listitem>
    </varlistentry>
    
    <varlistentry>
      <term>Use the serial comma</term>
      
      <listitem>
	<para>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 <quote>and</quote>.</para>

	<para>For example, look at the following:</para>
	
	<blockquote>
	  <para>This is a list of one, two and three items.</para>
	</blockquote>
	
	<para>Is this a list of three items, <quote>one</quote>,
	  <quote>two</quote>, and <quote>three</quote>, or a list of two items,
	  <quote>one</quote> and <quote>two and three</quote>?</para>
	
	<para>It is better to be explicit and include a serial comma:</para>
	
	<blockquote>
	  <para>This is a list of one, two, and three items.</para>
	</blockquote>
      </listitem>
    </varlistentry>
    
    <varlistentry>
      <term>Avoid redundant phrases</term>
      
      <listitem>
	<para>Try not to use redundant phrases.  In particular, <quote>the
	  command</quote>, <quote>the file</quote>, and <quote>man
	  command</quote> are probably redundant.</para>

	<para>These two examples show this for commands.  The second example
	  is preferred.</para>
	
	<informalexample>
	  <para>Use the command <command>cvsup</command> to update your
	    sources</para>
	</informalexample>
      
	<informalexample>
	  <para>Use <command>cvsup</command> to update your sources</para>
	</informalexample>
	
	<para>These two examples show this for filenames.  The second example
	  is preferred.</para>
	
	<informalexample>
	  <para>&hellip; in the filename
	    <filename>/etc/rc.local</filename>&hellip;</para>
	</informalexample>
	
	<informalexample>
	  <para>&hellip; in
	    <filename>/etc/rc.local</filename>&hellip;</para>
	</informalexample>
	
	<para>These two examples show this for manual references.  The second
	  example is preferred (the second example uses
	  <sgmltag>citerefentry</sgmltag>).</para>
	
	<informalexample>
	  <para>See <command>man csh</command> for more
	    information.</para>
	</informalexample>
	
	<informalexample>
	  <para>See &man.csh.1;</para>
	</informalexample>
      </listitem>
    </varlistentry>
    <varlistentry>
      <term>Two spaces at the end of sentences</term>

      <listitem>
	<para>Always use two spaces at the end of sentences, as this
	  improves readability, and eases use of tools such as
	  <application>Emacs</application>.</para>

	<para>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.  <quote>Jordan K. Hubbard</quote> is a good
	  example; it has a capital <literal>H</literal> following a
	  period and a space, and there certainly is not a new sentence
	  there.</para>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>For more information about writing style, see <ulink
      url="http://www.bartleby.com/141/">Elements of
      Style</ulink>, by William Strunk.</para>

  <sect1 id="writing-style-guide">
    <title>Style guide</title>

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

    <sect2>
      <title>Letter case</title>

      <para>Tags are entered in lower case, <literal>&lt;para&gt;</literal>,
	<emphasis>not</emphasis> <literal>&lt;PARA&gt;</literal>.</para>

      <para>Text that appears in SGML contexts is generally written in upper
	case, <literal>&lt!ENTITY&hellip;&gt;</literal>, and
	<literal>&lt;!DOCTYPE&hellip;&gt;</literal>, <emphasis>not</emphasis>
	<literal>&lt;!entity&hellip;&gt;</literal> and
	<literal>&lt;!doctype&hellip;&gt;</literal>.</para>
    </sect2>

    <sect2>
      <title>Acronyms</title>

      <para>Acronyms should generally be spelled out the first time
	they appear in a book, as in: "Network Time Protocol (<acronym
	role="Network Time Protocol">NTP</acronym>)." 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 book. But if you prefer, you can also
	define them the first time they appear in each chapter.</para>

      <para>The first three uses of an acronym should be enclosed in
        &lt;acronym&gt; tags, with a <literal>role</literal> 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.</para>
    </sect2>

    <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>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.</para>

      <para>For example, the source for this section looks something
	like:</para>

      <programlisting><![ CDATA [+--- 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>]]></programlisting>

      <para>If you use <application>Emacs</application> or
	<application>XEmacs</application> to edit the files then
	<literal>sgml-mode</literal> should be loaded automatically, and the
	<application>Emacs</application> local variables at the bottom of each file should enforce these
	styles.</para>

      <para><application>Vim</application> users might want to configure
	their editor with:</para>

      <programlisting>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</programlisting>

    </sect2>

    <sect2>
      <title>Tag style</title>

      <sect3>
	<title>Tag spacing</title>
	
	<para>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:</para>

	<informalexample>
	  <programlisting><![ CDATA [<article>
  <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>]]></programlisting>
	</informalexample>
      </sect3>

      <sect3>
	<title>Separating tags</title>

	<para>Tags like <sgmltag>itemizedlist</sgmltag> which will
	  always have further tags inside them, and in fact do not take
	  character data themselves, are always on a line by
	  themselves.</para>

	<para>Tags like <sgmltag>para</sgmltag> and
	  <sgmltag>term</sgmltag> do not need other tags to contain
	  normal character data, and their contents begin immediately
	  after the tag, <emphasis>on the same line</emphasis>.</para>

	<para>The same applies to when these two types of tags
	  close.</para>

	<para>This leads to an obvious problem when mixing these
	  tags.</para>

	<para>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.</para>

	<para>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.</para>
      </sect3>
    </sect2>

    <sect2>
      <title>White space changes</title>

      <para>When committing changes, <emphasis>do not commit changes to the
	  content at the same time as changes to the
	  formatting</emphasis>.</para>
      
      <para>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.</para>

      <para>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.</para>
    </sect2>

    <sect2>
      <title>Nonbreaking space</title>

      <para>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:</para>

      <literallayout class="monospaced">Data capacity ranges from 40 MB to 15
GB.  Hardware compression &hellip;</literallayout>

      <para>The general entity <literal>&amp;nbsp;</literal> prohibits
	line breaks between parts belonging together.  Use nonbreaking
	spaces in the following places:</para>

      <itemizedlist>
	<listitem>
	  <para>between numbers and units:</para>
	  <programlisting><![ CDATA [57600&nbsp;bps]]></programlisting>
	</listitem>

	<listitem>
	  <para>between program names and version numbers:</para>
	  <programlisting><![ CDATA [FreeBSD&nbsp;4.7]]></programlisting>
	</listitem>

	<listitem>
	  <para>between multiword names (use with caution when applying this
	    to more than 3-4 word names like <quote>The FreeBSD Brazilian
	      Portuguese Documentation Project</quote>):</para>
	  <programlisting><![ CDATA [Sun&nbsp;Microsystems]]></programlisting>  
	</listitem>
      </itemizedlist>
    </sect2>
  </sect1>

  <sect1 id="writing-style-word-list">
    <title>Word list</title>

    <para>The following is a small list of words spelled the way they
      should be used in the FreeBSD Documentation Project.  If the
      word you are looking for is not in this list, then please
      consult the <ulink
      url="http://www.oreilly.com/oreilly/author/stylesheet.html">O'Reilly
      word list</ulink>.</para>

    <itemizedlist>
      <listitem>
	<para>2.2.X</para>
      </listitem>

      <listitem>
	<para>4.X-STABLE</para>
      </listitem>

      <listitem>
	<para>CD-ROM</para>
      </listitem>

      <listitem>
	<para>DoS <emphasis>(Denial of Service)</emphasis> </para>
      </listitem>

      <listitem>
	<para>Ports Collection</para>
      </listitem>

      <listitem>
	<para>IPsec</para>
      </listitem>

      <listitem>
	<para>Internet</para>
      </listitem>

      <listitem>
	<para>MHz</para>
      </listitem>

      <listitem>
	<para>Soft Updates</para>
      </listitem>

      <listitem>
	<para>Unix</para>
      </listitem>

      <listitem>
	<para>disk label</para>
      </listitem>

      <listitem>
	<para>email</para>
      </listitem>

      <listitem>
	<para>file system</para>
      </listitem>

      <listitem>
	<para>manual page</para>
      </listitem>

      <listitem>
	<para>mail server</para>
      </listitem>

      <listitem>
	<para>name server</para>
      </listitem>

      <listitem>
	<para>null-modem</para>
      </listitem>

      <listitem>
	<para>web server</para>
      </listitem>
    </itemizedlist>

  </sect1>
</chapter>

<!--
     Local Variables:
     mode: sgml
     sgml-declaration: "../chapter.decl"
     sgml-indent-data: t
     sgml-omittag: nil
     sgml-always-quote-attributes: t
     sgml-parent-document: ("../book.sgml" "part" "chapter")
     End:
-->