blob: 9baab1278554dd3cfba0ee5674e5cb595735037c [file] [log] [blame]
Georg Brandl116aa622007-08-15 14:28:22 +00001.. highlightlang:: rest
2
Alexander Belopolskyea3e91e2010-11-11 22:43:45 +00003Style guide
Georg Brandl116aa622007-08-15 14:28:22 +00004===========
5
6The Python documentation should follow the `Apple Publications Style Guide`_
7wherever possible. This particular style guide was selected mostly because it
8seems reasonable and is easy to get online.
9
Alexander Belopolskyea3e91e2010-11-11 22:43:45 +000010Topics which are either not covered in Apple's style guide or treated
11differently in Python documentation will be discussed in this
12document.
13
14Use of whitespace
15-----------------
Georg Brandl116aa622007-08-15 14:28:22 +000016
Georg Brandl2592f622011-03-20 18:14:07 +000017All reST files use an indentation of 3 spaces; no tabs are allowed. The
18maximum line length is 80 characters for normal text, but tables, deeply
19indented code samples and long links may extend beyond that. Code example
20bodies should use normal Python 4-space indentation.
Georg Brandl116aa622007-08-15 14:28:22 +000021
22Make generous use of blank lines where applicable; they help grouping things
23together.
24
25A sentence-ending period may be followed by one or two spaces; while reST
26ignores the second space, it is customarily put in by some users, for example
27to aid Emacs' auto-fill mode.
28
Alexander Belopolskyea3e91e2010-11-11 22:43:45 +000029Footnotes
30---------
31
Georg Brandl116aa622007-08-15 14:28:22 +000032Footnotes are generally discouraged, though they may be used when they are the
33best way to present specific information. When a footnote reference is added at
34the end of the sentence, it should follow the sentence-ending punctuation. The
35reST markup should appear something like this::
36
37 This sentence has a footnote reference. [#]_ This is the next sentence.
38
39Footnotes should be gathered at the end of a file, or if the file is very long,
40at the end of a section. The docutils will automatically create backlinks to
41the footnote reference.
42
43Footnotes may appear in the middle of sentences where appropriate.
44
Alexander Belopolskyea3e91e2010-11-11 22:43:45 +000045Capitalization
46--------------
47
48.. sidebar:: Sentence case
49
50 Sentence case is a set of capitalization rules used in English
51 sentences: the first word is always capitalized and other words are
52 only capitalized if there is a specific rule requiring it.
53
54Apple style guide recommends the use of title case in section titles.
55However, rules for which words should be capitalized in title case
56vary greaty between publications.
57
58In Python documentation, use of sentence case in section titles is
59preferable, but consistency within a unit is more important than
60following this rule. If you add a section to the chapter where most
61sections are in title case you can either convert all titles to
62sentence case or use the dominant style in the new section title.
63
64Sentences that start with a word for which specific rules require
65starting it with a lower case letter should be avoided in titles and
66elsewhere.
67
68.. note::
69
70 Sections that describe a library module often have titles in the
71 form of "modulename --- Short description of the module." In this
72 case, the description should be capitalized as a stand-alone
73 sentence.
74
Georg Brandl116aa622007-08-15 14:28:22 +000075Many special names are used in the Python documentation, including the names of
76operating systems, programming languages, standards bodies, and the like. Most
77of these entities are not assigned any special markup, but the preferred
78spellings are given here to aid authors in maintaining the consistency of
79presentation in the Python documentation.
80
81Other terms and words deserve special mention as well; these conventions should
82be used to ensure consistency throughout the documentation:
83
84CPU
Alexander Belopolskyea3e91e2010-11-11 22:43:45 +000085 For "central processing unit." Many style guides say this should be
86 spelled out on the first use (and if you must use it, do so!). For
87 the Python documentation, this abbreviation should be avoided since
88 there's no reasonable way to predict which occurrence will be the
89 first seen by the reader. It is better to use the word "processor"
90 instead.
Georg Brandl116aa622007-08-15 14:28:22 +000091
92POSIX
Alexander Belopolskyea3e91e2010-11-11 22:43:45 +000093 The name assigned to a particular group of standards. This is always
94 uppercase.
Georg Brandl116aa622007-08-15 14:28:22 +000095
96Python
Alexander Belopolskyea3e91e2010-11-11 22:43:45 +000097 The name of our favorite programming language is always capitalized.
98
99reST
100 For "reStructuredText," an easy to read, plaintext markup syntax
101 used to produce Python documentation. When spelled out, it is
102 always one word and both forms start with a lower case 'r'.
Georg Brandl116aa622007-08-15 14:28:22 +0000103
104Unicode
Alexander Belopolskyea3e91e2010-11-11 22:43:45 +0000105 The name of a character coding system. This is always written
106 capitalized.
Georg Brandl116aa622007-08-15 14:28:22 +0000107
108Unix
Alexander Belopolskyea3e91e2010-11-11 22:43:45 +0000109 The name of the operating system developed at AT&T Bell Labs in the early
110 1970s.
Georg Brandl116aa622007-08-15 14:28:22 +0000111
112
Georg Brandl386bc6d2010-04-25 10:19:53 +0000113.. _Apple Publications Style Guide: http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2009.pdf
Georg Brandl116aa622007-08-15 14:28:22 +0000114