Skip to content

Commit cb5167c

Browse files
committed
change recommended max line length to 120 and rewrap the doc itself accordingly
1 parent ebcc151 commit cb5167c

File tree

1 file changed

+31
-47
lines changed

1 file changed

+31
-47
lines changed

doc/source/contribute.rst

Lines changed: 31 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -6,13 +6,10 @@ Getting the code (for the first time)
66

77
- install a Git client
88

9-
On Windows, TortoiseGit provides a nice graphical wrapper. You need to
10-
install both the console client from http://msysgit.github.io/ and
11-
`TortoiseGit <https://code.google.com/p/tortoisegit>`_
12-
itself.
9+
On Windows, TortoiseGit provides a nice graphical wrapper. You need to install both the console client from
10+
http://msysgit.github.io/ and `TortoiseGit <https://code.google.com/p/tortoisegit>`_ itself.
1311

14-
- create an account on `GitHub <https://github.com/>`_ (not necessary for
15-
readonly).
12+
- create an account on `GitHub <https://github.com/>`_ (not necessary for readonly).
1613

1714
- clone the repository on your local machine ::
1815

@@ -26,14 +23,13 @@ You could install LArray in the standard way: ::
2623

2724
> python setup.py install
2825

29-
but in that case you need to "install" it again every time you change it. When
30-
developing, it is usually more convenient to use: ::
26+
but in that case you need to "install" it again every time you change it. When developing, it is usually more
27+
convenient to use: ::
3128

3229
> python setup.py develop
3330

34-
This creates some kind of symlink between your python installation "modules"
35-
directory and your repository, so that any change in your local copy is
36-
automatically usable by other modules.
31+
This creates some kind of symlink between your python installation "modules" directory and your repository, so that any
32+
change in your local copy is automatically usable by other modules.
3733

3834

3935
Updating your local copy with remote changes
@@ -47,13 +43,11 @@ Updating your local copy with remote changes
4743
Code conventions
4844
----------------
4945

50-
`PEP8 <http://www.python.org/dev/peps/pep-0008/>`_ is your friend. Among others,
51-
this means:
46+
`PEP8 <http://www.python.org/dev/peps/pep-0008/>`_ is your friend. Among others, this means:
5247

53-
- 80 characters lines
48+
- 120 characters lines
5449
- 4 spaces indentation
55-
- lowercase (with underscores if needed) variables, functions, methods and
56-
modules names
50+
- lowercase (with underscores if needed) variables, functions, methods and modules names
5751
- CamelCase classes names
5852
- all uppercase constants names
5953
- whitespace around binary operators
@@ -92,7 +86,7 @@ We use Numpy conventions for docstrings. Here is a template: ::
9286

9387
Returns
9488
-------
95-
name : type
89+
type
9690
Description of return value.
9791

9892
See Also
@@ -119,9 +113,8 @@ For example: ::
119113

120114
Returns
121115
-------
122-
result : bool
123-
Whether the string representation of the number is equal to the
124-
string.
116+
bool
117+
Whether the string representation of the number is equal to the string.
125118

126119
Examples
127120
--------
@@ -138,21 +131,18 @@ For example: ::
138131
Documentation
139132
-------------
140133

141-
The documentation is written using reStructuredText and built to various
142-
formats using `Sphinx <http://sphinx-doc.org/>`_. See the `reStructuredText
143-
Primer <http://sphinx-doc.org/rest.html#rst-primer>`_ for a first introduction
144-
of the syntax.
134+
The documentation is written using reStructuredText and built to various formats using
135+
`Sphinx <http://sphinx-doc.org/>`_. See the `reStructuredText Primer <http://sphinx-doc.org/rest.html#rst-primer>`_
136+
for a first introduction of the syntax.
145137

146138
Installing Requirements
147139
~~~~~~~~~~~~~~~~~~~~~~~
148140

149-
Basic requirements (to generate an .html version of the documentation) can be
150-
installed using: ::
141+
Basic requirements (to generate an .html version of the documentation) can be installed using: ::
151142

152143
> conda install sphinx numpydoc
153144

154-
To build the .pdf version, you need a LaTeX processor. We use
155-
`MiKTeX <http://miktex.org>`_.
145+
To build the .pdf version, you need a LaTeX processor. We use `MiKTeX <http://miktex.org>`_.
156146

157147
To build the .chm version, you need `HTML Help Workshop
158148
<http://www.microsoft.com/en-us/download/details.aspx?id=21138>`_.
@@ -165,27 +155,26 @@ Open a command prompt and go to the documentation directory: ::
165155

166156
> cd doc
167157

168-
If you just want to check that there is no syntax error in the documentation
169-
and that it formats properly, it is usually enough to only generate the .html
170-
version, by using: ::
158+
If you just want to check that there is no syntax error in the documentation and that it formats properly, it is
159+
usually enough to only generate the .html version, by using: ::
171160

172161
> make html
173162

174163
Open the result in your favourite web browser. It is located in: ::
175164

176165
build/html/index.html
177166

178-
If you want to also generate the .pdf and .chm (and you have the extra
179-
requirements to generate those), you could use: ::
167+
If you want to also generate the .pdf and .chm (and you have the extra requirements to generate those), you could
168+
use: ::
180169

181170
> buildall
182171

183172

184173
Tests
185174
-----
186175

187-
We use both unit tests and doctests. Unit tests are written using Python's
188-
built-in `unittest module <https://docs.python.org/3/library/unittest.html>`_.
176+
We use both unit tests and doctests. Unit tests are written using Python's built-in
177+
`unittest module <https://docs.python.org/3/library/unittest.html>`_.
189178
For example: ::
190179

191180
from unittest import TestCase
@@ -205,12 +194,10 @@ To run all unit tests: ::
205194

206195
> python -m unittest -v larray\tests\test_la.py
207196

208-
We also use doctests for some tests. Doctests is specially-formatted code
209-
within the docstring of a function which embeds the result of calling said
210-
function with a particular set of arguments. This can be used both as
211-
documentation and testing. We only use doctests for the cases where the test is
212-
simple enough to fit on one line and it can help understand what the function
213-
does. For example: ::
197+
We also use doctests for some tests. Doctests is specially-formatted code within the docstring of a function which
198+
embeds the result of calling said function with a particular set of arguments. This can be used both as documentation
199+
and testing. We only use doctests for the cases where the test is simple enough to fit on one line and it can help
200+
understand what the function does. For example: ::
214201

215202
def slice_to_str(key):
216203
"""Converts a slice to a string
@@ -225,8 +212,7 @@ To run doc tests: ::
225212

226213
> python -m doctest -v larray\larray.py
227214

228-
To run both at the same time, one can use nosetests (install with `conda
229-
install nose`): ::
215+
To run both at the same time, one can use nosetests (install with `conda install nose`): ::
230216

231217
> nosetests -v --with-doctest
232218

@@ -236,11 +222,9 @@ Sending your changes
236222

237223
::
238224

239-
> git add # tell git it should care about a file it previously
240-
# ignored (only if needed)
225+
> git add # tell git it should care about a file it previously ignored (only if needed)
241226

242-
> git commit # creates a new revision of the repository using its
243-
# current state
227+
> git commit # creates a new revision of the repository using its current state
244228

245229
> git pull # updates your local repository with "upstream" changes.
246230
# this might create conflicts that you will need to resolve.

0 commit comments

Comments
 (0)