Merge pull request #1715 from jhlegarreta/StyleGuidelineSyntaxFixes

DOC: Avoid the bullet points being interpreted as quoted blocks.

doc/devel/coding_style_guideline.rst

@@ -6,20 +6,20 @@ DIPY Coding Style Guideline
 
 The main principles behind DIPY_ development are:
 
-  * **Robustness**: the results of a piece of code must be verified
-    systematically, and hence stability and robustness of the code must be
-    ensured, reducing code redundancies.
-  * **Readability**: the code is written and read by humans, and it is read
-    much more frequently than it is written.
-  * **Consistency**: following these guidelines will ease reading the code,
-    and will make it less error-prone.
-  * **Documentation**: document the code. Documentation is essential as it is
-    one of the key points for the adoption of DIPY as the toolkit of choice in
-    diffusion by the scientific community. Documenting helps clarifying
-    certain choices, helps avoiding obscure places, and is a way to allow
-    other members *decode* it with less effort.
-  * **Language**: the code must be written in English. Norms and spelling
-    should be abided by.
+* **Robustness**: the results of a piece of code must be verified
+  systematically, and hence stability and robustness of the code must be
+  ensured, reducing code redundancies.
+* **Readability**: the code is written and read by humans, and it is read
+  much more frequently than it is written.
+* **Consistency**: following these guidelines will ease reading the code,
+  and will make it less error-prone.
+* **Documentation**: document the code. Documentation is essential as it is
+  one of the key points for the adoption of DIPY as the toolkit of choice in
+  diffusion by the scientific community. Documenting helps clarifying
+  certain choices, helps avoiding obscure places, and is a way to allow
+  other members *decode* it with less effort.
+* **Language**: the code must be written in English. Norms and spelling
+  should be abided by.
 
 ------------
 Coding style
@@ -83,31 +83,31 @@ files, and with the consistency criterion in mind, beyond the numpy
 docstring standard aspects, contributors are encouraged to observe the
 following guidelines:
 
-  * The acronym for the Diffusion Imaging in Python toolkit should be written
-    as **DIPY**.
-  * The classes, objects, and any other construct referenced from the code
-    should be written with inverted commas, such as in *In DIPY, we use an
-    object called ``GradientTable`` which holds all the acquisition specific
-    parameters, e.g. b-values, b-vectors, timings and others.*
-  * Cite the relevant papers. Use the *[NameYear]* convention for
-    cross-referencing them, such as in [Garyfallidis2014]_, and put them
-    under the :ref:`references` section.
-  * Cross-reference related examples and files. Use the
-    ``.. _specific_filename:`` convention to label a file at the top of it.
-    Thus, other pages will be able to reference the file using the standard
-    Sphinx syntax ``:ref:`specific_filename```.
-  * Use an all-caps scheme for acronyms, and capitalize the first letters of
-    the long names, such as in *Constrained Spherical Deconvolution (CSD)*,
-    except in those cases where the most common convention has been to use
-    lowercase, such as in *superior longitudinal fasciculus (SLF)*.
-  * As customary in Python, use lowercase and separate words with underscores
-    for filenames, labels for references, etc.
-  * When including figures, use the regular font for captions (i.e. do not use
-    bold faces), unless otherwise required for a specific text part (e.g. a
-    DIPY object, etc.).
-  * When referring to relative paths, use the backquote inline markup
-    convention, such as in ``doc/devel``. Do not add the
-    greater-than/less-than signs to enclose the path.
+* The acronym for the Diffusion Imaging in Python toolkit should be written
+  as **DIPY**.
+* The classes, objects, and any other construct referenced from the code
+  should be written with inverted commas, such as in *In DIPY, we use an
+  object called ``GradientTable`` which holds all the acquisition specific
+  parameters, e.g. b-values, b-vectors, timings and others.*
+* Cite the relevant papers. Use the *[NameYear]* convention for
+  cross-referencing them, such as in [Garyfallidis2014]_, and put them
+  under the :ref:`references` section.
+* Cross-reference related examples and files. Use the
+  ``.. _specific_filename:`` convention to label a file at the top of it.
+  Thus, other pages will be able to reference the file using the standard
+  Sphinx syntax ``:ref:`specific_filename```.
+* Use an all-caps scheme for acronyms, and capitalize the first letters of
+  the long names, such as in *Constrained Spherical Deconvolution (CSD)*,
+  except in those cases where the most common convention has been to use
+  lowercase, such as in *superior longitudinal fasciculus (SLF)*.
+* As customary in Python, use lowercase and separate words with underscores
+  for filenames, labels for references, etc.
+* When including figures, use the regular font for captions (i.e. do not use
+  bold faces), unless otherwise required for a specific text part (e.g. a
+  DIPY object, etc.).
+* When referring to relative paths, use the backquote inline markup
+  convention, such as in ``doc/devel``. Do not add the
+  greater-than/less-than signs to enclose the path.
 
 
 .. _references: