Changes between Version 6 and Version 7 of DevelopmentIdeas/ModularOptimization

Timestamp:

05/01/07 04:41:29 (6 years ago)

Author:

mforbes

Comment:

Updated docstring and coding standards links

DevelopmentIdeas/ModularOptimization

@@ +1 @@
+[[PageOutline]]
 = Modular Optimization and Root Finding =
 This page contains discussions about a modularized optimization and root finding package.  Please make copious changes and add lots of comments and discussions.  We should refactor once it becomes large.  Once ideas are clearly formed, they should be posted to the !SciPy-dev mailing list for comments and suggestions.
 
-[[PageOutline(5,Contents,inline)]] (Why does this macro not work to generate the table of contents?)
-
 == Module Structure ==
-For now I am putting everything in an `moptimize` module for "Modular Optimization".  Hopefully this will be able to replace the scipy.optimize module at somepoint.  Note that coding standards, etc. can be found at the following sites:
- * [http://www.python.org/dev/peps/pep-0008/ PEP 8] -- Generic python coding standards.
- * TestingGuidelines -- !NumPy/!SciPy testing guidelines.
- * [source:trunk/FORMAT_GUIDELINES.txt FORMAT_GUIDELINES.txt] -- !SciPy naming standards: use_this_format_for_everything.  I can't find any discussion of this and it is very annoying as python class names typically have !CapWords as specified in PEP 8.   This should be checked with the newsgroup before finally deciding on names.
- * [source:../../numpy/browser/trunk/numpy/doc/HOWTO_DOCUMENT.txt numpy/doc/HOWTO_DOCUMENT.txt] -- !NumPy/!SciPy docstring standards to be complient with epydoc.
- * [http://www.scipy.org/DocstringStandard SciPy/DocstringStandard] -- Older !NumPy/!SciPy docstring standard proposal.
-
+For now I am putting everything in an `moptimize` module for "Modular Optimization".  Hopefully this will be able to replace the scipy.optimize module at somepoint.  
 {{{
 moptimize 
@@ -24 +17 @@
    ...
 }}}
+
+== Coding Guidelines ==
+ 1. '''Style:'''  Please install [http://www.logilab.org/857 pylint] and run it often as a check on your code quality.
+  * [http://www.python.org/dev/peps/pep-0008/ Style Guide for Python Code (PEP 8)]
+  * [http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines Numpy Style Guide]
+ * [source:trunk/FORMAT_GUIDELINES.txt FORMAT_GUIDELINES.txt] -- !SciPy naming standards: use_this_format_for_everything.  I can't find any discussion of this and it is very annoying as python class names typically have !CapWords as specified in PEP 8.   This should be checked with the newsgroup before finally deciding on names.
+ 1. '''Testing:'''  Please note that good documentation strings and unit tests are a crucial part of Scipy code base.  These are absolutely necessary for your code to be usable by others.
+  * TestingGuidelines
+ 1. '''Documentation:'''
+  * [http://projects.scipy.org/scipy/numpy/wiki/DocstringStandards Docstring standards]
+  * [http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc/HOWTO_DOCUMENT.txt How To Document]
+ 1. '''License:''' All Scipy code should be made available under a revised BSD-style license.
+
 == Interface ==
 There should be a very simple interface with default options and methods specified to get code working.  One should then be able to refine the method to suit the particular problem.  Ultimately, it might be nice to provide tools that could try different methods and parameter values to determine the "optimum" solver for a given problem.