aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml
blob: fb6746f935a79e08f50146760561a0fd88dccf5c (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
<!-- 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.

     $Id: chapter.sgml,v 1.4 1999-09-03 17:22:43 nik Exp $
-->

<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>Do not use contractions</term>
      
      <listitem>
	<para>Do not use contractions.  Always spell the phrase out in full.
	  &ldquo;Don't use contractions&rdquo; would be wrong.</para>

	<para>Avoiding contractions makes for a more formal tone, is more
	  precise, and slightly easier for translators.</para>
      </listitem>
    </varlistentry>
    
    <varlistentry>
      <term>Use the serial comma</term>
      
      <listitem>
	<para>In a list of items within a paragraph, seperate each item from
	  the others with a comma.  Seperate the last item from the others with
	  a comma and the word &ldquo;and&rdquo;.</para>

	<para>For example, look at the following quote;</para>
	
	<blockquote>
	  <para>This is a list of one, two and three items.</para>
	</blockquote>
	
	<para>Is this a list of three items, &ldquo;one&rdquo;,
	  &ldquo;two&rdquo;, and &ldquo;three&rdquo;, or a list of two items,
	  &ldquo;one&rdquo; and &ldquo;two and three&rdquo;?</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, &ldquo;the
	  command&rdquo;, &ldquo;the file&rdquo;, and &ldquo;man
	  command&rdquo; 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>
  </variablelist>

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

  <sect1>
    <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>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>

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

      <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>]]></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
	Emacs local variables at the bottom of each file should enforce these
	styles.</para>
    </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 sentances 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>
  </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:
-->