lines less than 80 chars in /writing/

This commit is contained in:
Tomas Thor Jonsson
2012-04-23 20:24:39 +02:00
parent 6978c5a1ae
commit 70ca1a8cef
4 changed files with 55 additions and 41 deletions
+9 -3
View File
@@ -38,7 +38,8 @@ Docstrings
PEP 257 is the primary reference for docstrings. (http://www.python.org/dev/peps/pep-0257/)
There are two types of docstrings, one-line and multi-line. Their names should be fairly self explanatory.
There are two types of docstrings, one-line and multi-line. Their names
should be fairly self explanatory.
One-line docstrings: ::
def kos_root():
@@ -63,7 +64,9 @@ Multi-line docstrings: ::
Sphinx
------
Sphinx_ is a tool which converts documentation in the :ref:`restructuredtext-ref` markup language into a range of output formats including HTML, LaTeX (for printable PDF versions), manual pages and plain text.
Sphinx_ is a tool which converts documentation in the :ref:`restructuredtext-ref`
markup language into a range of output formats including HTML, LaTeX (for
printable PDF versions), manual pages and plain text.
.. note:: This Guide is built with Sphinx_
@@ -75,7 +78,10 @@ Sphinx_ is a tool which converts documentation in the :ref:`restructuredtext-ref
reStructuredText
----------------
Most Python documentation is written with reStructuredText_. The `reStructuredText Primer <http://sphinx.pocoo.org/rest.html>`_ and the `reStructuredText Quick Reference <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`_ should help you familiarize yourself with its syntax.
Most Python documentation is written with reStructuredText_. The
`reStructuredText Primer <http://sphinx.pocoo.org/rest.html>`_ and the
`reStructuredText Quick Reference <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`_
should help you familiarize yourself with its syntax.
.. _reStructuredText: http://docutils.sourceforge.net/rst.html
+4 -2
View File
@@ -3,9 +3,11 @@ Choosing a License
Open source.
There are plenty of `open source licenses <http://opensource.org/licenses/alphabetical>`_ available to choose from.
There are plenty of `open source licenses <http://opensource.org/licenses/alphabetical>`_
available to choose from.
To help you choose one for your project, there's a `license chooser <http://three.org/openart/license_chooser/>`_, use it.
To help you choose one for your project, there's a `license chooser <http://three.org/openart/license_chooser/>`_,
use it.
Non-Restrictive
+17 -13
View File
@@ -261,7 +261,8 @@ keep a count of your place in the list.
# 1, 4
# 2, 5
The ``enumerate`` function has better readability than handling a counter manually. Moreover,
The ``enumerate`` function has better readability than handling a counter
manually. Moreover,
it is better optimized for iterators.
Read From a File
@@ -287,8 +288,8 @@ files for you.
for line in f:
print line
The ``with`` statement is better because it will ensure you always close the file,
even if an exception is raised.
The ``with`` statement is better because it will ensure you always close the
file, even if an exception is raised.
Returning Multiple Values from a Function
-----------------------------------------
@@ -320,15 +321,17 @@ values in before you return
Line Continuations
~~~~~~~~~~~~~~~~~~
When a logical line of code is longer than the accepted limit, you need to split it over multiple
physical lines. Python interpreter will join consecutive lines if the last character of the line is
a backslash. This is helpful sometime but is preferably avoided, because of its fragility: a white
space added to the end of the line, after the backslash, will break the code and may have unexpected
results.
When a logical line of code is longer than the accepted limit, you need to
split it over multiple physical lines. Python interpreter will join consecutive
lines if the last character of the line is a backslash. This is helpful
sometime but is preferably avoided, because of its fragility: a white space
added to the end of the line, after the backslash, will break the code and may
have unexpected results.
A prefered solution is to use parenthesis around your elements. Left with an unclosed parenthesis on an end-of-line
the Python interpreter will join the next line until the parenthesis is closed. The same behavior holds for
curly and square braces.
A prefered solution is to use parenthesis around your elements. Left with an
unclosed parenthesis on an end-of-line the Python interpreter will join the
next line until the parenthesis is closed. The same behavior holds for curly
and square braces.
**Bad**:
@@ -352,5 +355,6 @@ curly and square braces.
from some.deep.module.inside.a.module import (a_nice_function, another_nice_function,
yet_another_nice_functio)
However, more often than not having to split long logical line is a sign that you
are trying to do too many things at the same time, which may hinder readability.
However, more often than not having to split long logical line is a sign that
you are trying to do too many things at the same time, which may hinder
readability.
+25 -23
View File
@@ -21,9 +21,10 @@ Some general rules of testing:
- Try hard to make tests that run fast. If one single test needs more than a
few millisecond to run, development will be slowed down or the tests will not
be run as often as desirable. In some cases, test can't be fast because they
need a complex data structure to work on, and this data structure must be loaded
every time the test runs. Keep these heavier tests in a separate test suite
that is run by some scheduled task, and run all other tests as often as needed.
need a complex data structure to work on, and this data structure must be
loaded every time the test runs. Keep these heavier tests in a separate test
suite that is run by some scheduled task, and run all other tests as often
as needed.
- Learn your tools and learn how to run a single test or a test case. Then,
when developing a function inside a module, run this function's tests very
@@ -41,9 +42,9 @@ Some general rules of testing:
When comming back to work, you will have a pointer to where you were and get
faster on tracks.
- The first step when you are debugging your code is to write a new test pinpointing
the bug. While it is not always possible to do, those bug catching test are among
the most valuable piece of code in your project.
- The first step when you are debugging your code is to write a new test
pinpointing the bug. While it is not always possible to do, those bug
catching test are among the most valuable piece of code in your project.
- Use long and descriptive names for testing functions. The style guide here is
slighlty different than that of running code, where short names are often
@@ -62,10 +63,10 @@ Some general rules of testing:
- Another use of the testing code is as an introduction to new developers. When
someone will have to work on the code base, runnning and reading the related
testing code is often the best they can do. They will or should discover the
hot spots, where most difficulties arise, and the corner cases. If they have to
add some functionality, the first step should be to add a test and, by this mean,
ensure the new functionality is not already a working path that has not been
plugged in the interface.
hot spots, where most difficulties arise, and the corner cases. If they have
to add some functionality, the first step should be to add a test and, by this
mean, ensure the new functionality is not already a working path that has not
been plugged in the interface.
The Basics
::::::::::
@@ -99,15 +100,15 @@ As of Python 2.7 unittest also includes its own test discovery mechanisms.
Doctest
-------
The doctest module searches for pieces of text that look like interactive Python
sessions in docstrings, and then executes those sessions to verify that they work exactly as
shown.
The doctest module searches for pieces of text that look like interactive
Python sessions in docstrings, and then executes those sessions to verify that
they work exactly as shown.
Doctests have a different use case than proper unit tests: they are usually less
detailed and don't catch special cases or obscure regression bugs. They are
useful as an expressive documentation of the main use cases of a module and
its components. However, doctests should run automatically each time
the full test suite runs.
Doctests have a different use case than proper unit tests: they are usually
less detailed and don't catch special cases or obscure regression bugs. They
are useful as an expressive documentation of the main use cases of a module and
its components. However, doctests should run automatically each time the full
test suite runs.
A simple doctest in a function:
@@ -128,8 +129,9 @@ A simple doctest in a function:
import doctest
doctest.testmod()
When running this module from the command line as in ``python module.py``, the doctests
will run and complain if anything is not behaving as described in the docstrings.
When running this module from the command line as in ``python module.py``, the
doctests will run and complain if anything is not behaving as described in the
docstrings.
Tools
:::::
@@ -144,7 +146,7 @@ py.test is a no-boilerplate alternative to Python's standard unittest module.
$ pip install pytest
Despite being a fully-featured and extensible test tool it boasts a simple
Despite being a fully-featured and extensible test tool it boasts a simple
syntax. Creating a test suite is as easy as writing a module with a couple of
functions
@@ -205,8 +207,8 @@ xUnit-compatible test output, coverage reporting, and test selection.
tox
---
tox is a tool for automating test environment management and testing against multiple
interpreter configurations
tox is a tool for automating test environment management and testing against
multiple interpreter configurations
::