epifanio
/
grassgis
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

SUBMITTING files moved to Trac http://trac.osgeo.org/grass/wiki/Submitting 

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@61014 15284696-431f-4ddb-bdfa-cd5b030d7da7
py3
martinl 2014-06-27 15:08:33 +00:00
parent fe5ae2c97d
commit 7a7e72e4c3
4 changed files with 1 additions and 960 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

497
SUBMITTING
View File

@ -1,496 +1 @@
NOTE: Please improve this list!
Dear (new) GRASS developer,
when submitting C code to GRASS SVN repository, please take care of
following rules:
[ see SUBMITTING_PYTHON for Python code hints ]
[ see SUBMITTING_WXGUI for wxPython GUI code hints ]
[ see SUBMITTING_DOCS for documentation ]
1. Get and read the GRASS Programmer's Manual here:
http://grass.osgeo.org/programming7/
or generate it from this source code (the programmer's manual is
integrated in the source code in doxygen style):
make htmldocs
make pdfdocs
2. Use the directory structure to place your module appropriately into
the source tree
- libes go into lib/
- raster modules go into raster/
- vector modules go into vector/
- ...
Consider to take a look at "GNU Coding Standards"
http://www.gnu.org/prep/standards.html
3. Add a header section to each file you submit and make sure you
include the copyright. The purpose section is meant to contain a
general overview of the code in the file to assist other
programmers that will need to make changes to your code. If you
are modifying an existing file you may under no circumstances
remove prior copyright or licensing text that is not your own,
even for a major rewrite. If any original code or code that is in
part derived from another's original work remains, it must be
properly cited.
Example (ficticious header for a file called color.c) :
/****************************************************************************
*
* MODULE: g.foo
* AUTHOR(S): John Doe <jdoe at somewhere org>
* PURPOSE: Provide short description of module here...
* COPYRIGHT: (C) 2010 by John Doe, and the GRASS Development Team
*
* This program is free software under the GNU General Public
* License (>=v2). Read the COPYING file that comes with GRASS
* for details.
*
*****************************************************************************/
The copyright protects your rights according to GNU General Public
License (www.gnu.org).
4. We don't want the $ID$ in source code any more as it causes problems
for the SVN branches.
5. To ensure that the software system continues to work, please include
#include <grass/config.h>
in your files and make use of the various system dependencies
contained therein. As one example of this, see lib/gmath/fft.c.
Please refrain from declaring system functions within the
software; include the proper header files (conditionally dependent
on config.h macros if necessary) instead.
6. Order of include headers
In general, headers should be included in the order:
1. Core system headers (stdio.h, ctype.h, ...)
2. Headers for non-core system components (X11, libraries).
3. Headers for core systems of the package being compiled (grass/gis.h, grass/glocale.h, ...)
4. Headers for the specific library/program being compiled (geodesic.h, ...)
Each class of header has an obligation to be compatible with those
above it in the list, but not those below it.
7. Always specify the return type for ALL functions including those that
return type "void", and insert return statements for any function
which returns a value.
Also, use ANSI C prototypes to declare your functions.
For module return values, see "Exit status" below.
Examples:
void G_something(void);
int G_something_else(int, int);
void G_something(void)
{
/* Snipped out code */
return;
}
int G_something_else(int x, int y)
{
/* Snipped out code */
return 0;
}
8. Module exit status is defined as EXIT_SUCCESS or EXIT_FAILURE
(declared in stdlib.h), e.g.
{
...
if (G_parser (argc, argv))
exit (EXIT_FAILURE);
...
exit (EXIT_SUCCESS);
}
9. Use fprintf() instead of printf()
For errors and warnings please use the G_fatal_error() and
G_warning() functions. General messages for the user should use
G_message() while debug messages should use G_debug() whenever
possible. There are two variants to G_message(): G_verbose_message()
which will only display the message if in --verbose mode, and
G_important_message() which will always show the message unless
the module is running in --quiet mode. G_fatal_error() and
G_warning() will always be displayed regardless of verbosity setting.
Messages sent to any of these functions will be printed to stderr.
G_message() output is not expected to be sent to pipe or file.
Always use the gettext macros with _("") for user messages,
example:
G_fatal_error(_("Vector map <%s> not found"), name);
It is suggested to add a comment line before translatable user message
to give a hint to translators about meaning or use of
cumbersome or obscure message. First word in the comment must be GTC
- GRASS translation comment,
example:
/* GTC A name of a projection */
G_message(_("State Plane"));
Any message with a noun in plural form has to pass _n() macro,
even if for the English language it is not required!
G_message(_n("One map", "%d maps", number), number);
See locale/README for details.
Pipe/file data output:
For data output redirected to pipe or file, please use fprintf() and
specify the stdout stream as follows:
fprintf(stdout, ...);
fflush(stdout);
fflush(stdout) always required when using fprintf(stdout, ...).
10. Use the GRASS library function G_asprintf() instead of the
standard C functions asprintf(), vsnprintf() and snprintf(). These
functions are not portable or have other issues. Example:
char *msg;
G_asprintf(&msg, "%s", parameters);
do_something_with_msg();
G_free(msg);
Note that you should free memory when G_asprintf() is used.
11. Use the following GRASS library functions instead of the standard C
functions. The reason for this is that the following functions ensure
good programming practice (e.g. always checking if memory was allocated)
and/or improves portability. PLEASE refer to the programmers manual
for the proper use (e.g. determining if any casts are needed for arguments
or return values) of these library functions. They may perform a task
slightly different from their corresponding C library function, and thus,
their use may not be the same.
G_malloc() instead of malloc()
G_calloc() instead of calloc()
G_realloc() instead of realloc()
G_free() instead of free()
G_getenv() instead of getenv()
G_setenv() instead of setenv()
G_unsetenv() instead of unsetenv()
G_sleep() instead of sleep()
Could somebody please add others (please verify that they are
useful and safe first)
12. Use function names which fulfill the official GNU naming convention.
http://www.gnu.org/prep/standards/html_node/Names.html#Names
Instead of naming a function like: MyNewFunction() use underscores
for seperation and lower case letters: my_new_function().
13. Don't use the C++ comment style! This confuses several compilers.
Use instead:
/* C-comments */
If you want to comment code portions, use
#ifdef notdef
portion_to_be_commented;
#endif
This is safe comparing to nested /* comments */
Functions in the library must be documented in doxygen style to
get them into the programmer's manual (generate with
make pdfdocs or
make htmldocs
). See lib/gis/*.c for examples.
14. PLEASE take the time to add comments throughout your code explaining what
the code is doing. It will save a HUGE amount of time and frustration for
other programmers that may have to change your code in the future.
15. To promote a consistent coding style, please use the "indent" program
on all new C modules using the following switches:
$ indent -bad -bap -bbb -br -bli0 -bls -cli0 -ncs -fc1 -hnl -i4 \
-nbbo -nbc -nbfda -nbfde -ncdb -ncdw -nce -nfca -npcs -nprs \
-npsl -nsc -nsob -saf -sai -saw -sbi0 -ss -ts8 -ut main.c
Existing code should not be re-indented except in extreme cases, as this
will make "diff" comparisons with older versions impossible. If indent is
needed, do not check in any changes other than the indentation in the same
commit! Do add the indent switches and any indent warning messages to the
SVN log. Any change or fix mixed in with an indent is very hard to track
making it hard for others to follow the change or fix any new bugs.
For your convenience use the tools/grass_indent.sh script.
16. Platform dependent code:
Do not remove #ifdef __CYGWIN__ and/or #ifndef __CYGWIN__ lines and
their encapsulated lines from source code (one example was that someone
removed drand48 definition.)
17. Suggested compiler flags:
We suggest to use very strict compiler flags to capture errors
at the very beginning. Here our list of flags, please use them
to configure you development version of GRASS:
GNU/Linux:
MYCFLAGS="-g -Wall -Werror-implicit-function-declaration -fno-common"
MYCXXFLAGS="-g -Wall"
CFLAGS="$MYCFLAGS" CXXFLAGS="$MYCXXFLAGS" ./configure ...
MacOSX: [to be suggested]
MS-Windows: [to be suggested]
18. Make sure a new line is at the end of each file and UNIX style newlines
are used (\n).
19. When writing Makefiles, use the current standard.
If you have to use commands, please check for:
avoid | use instead
------------------+---------------
make target | $(MAKE) target
mkdir target | $(MKDIR) target
cp (executable) | $(INSTALL) -m 755 file target
cp (normal file) | $(INSTALL) -m 644 file target
ar | $(AR)
rm: be VERY careful with recursive remove. Also beware of
removing $(FOO)* if $(FOO) has any chance of being empty.
Examples: see below examples or others
raster/r.info/Makefile
vector/v.edit/Makefile
If you are unsure, please ask on the GRASS Developers list.
20. Have a look at ./INSTALL
21. Have a function included in your module which writes to the history
file of the map (e.g. command line, parameters etc.). See e.g.
raster/r.patch/main.c
(the same applies to vector and g3d modules!)
22. Standard parser options: use G_define_standard_option() whenever possible
to define standard module command line options. This will save you time,
create fewer bugs, and make things easier on the translators.
See lib/gis/parser.c for details of the function definition.
23. Add/update, if required the related GUI menus:
gui/wxpython/xml/menudata.xml
24. For consistency, use README rather than README.txt for any README files.
25. GRASS/Environment variables:
If you add a new variable, please follow the naming convention.
All variables are described in
lib/init/variables.html
26. Be sure to develop on top of the LATEST GRASS code (which is in our SVN
repository). You can re-check before submission with 'svn diff':
Be sure to create unified ("diff -u") format. "Plain" diffs (the default
format) are risky, because they will apply without warning to code which
has been substantially changed; they are also harder to read than unified.
Such diffs should be made from the top-level directory, e.g.
"svn diff display/d.vect/main.c"; that way, the diff will
include the pathname rather than just an ambiguous "main.c".
27. Try to use module names which describe shortly the intended purpose of the module.
The first letters for module name should be:
d. - display commands
db. - database commands
g. - general GIS management commands
i. - imagery commands
m. - miscellaneous tool commands
ps. - postscript commands
r. - raster commands
r3. - raster3D commands
v. - vector commands
Some additional naming conventions
* export modules: (type).out.(format) eg: r.out.arc, v.out.ascii
* import module: (type).in.(format) eg: r.in.arc, v.in.ascii
* conversion modules: (type).to.(type) eg: r.to.vect, v.to.rast, r3.to.rast
Avoid module names with more than two dots in the name.
Example:
instead of r.to.rast3.elev use r.to.rast3elev
28. Use the grass test suite to test your modules.
http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite
You can easily write specific tests for your modules.
If your module is part of GRASS and you created some standard test
cases, please contact the developers to add your tests to the
default test suite. This will automatize complex test scenarios
and assure to find bugs much faster, if changes were made to your
modules or to the grass library.
Consider to subscribe to the GRASS Quality Assessment System to
get immediate notification about the code quality:
http://lists.osgeo.org/mailman/listinfo/grass-qa
29. When submitting new files to the repository set SVN properties,
usually for directory
svn:ignore : *.tmp.html
*OBJ*
or e.g. for C-file
svn:mime-type : text/x-csrc
svn:keywords : Author Date Id
svn:eol-style : native
See
http://svnbook.red-bean.com/en/1.4/svn.advanced.props.html
To set a property:
svn propset svn:keywords 'Author Date Id' <file>
svn propset svn:mime-type text/x-sh grass_shellscript.sh
To edit the svn:ignore property using your default text editor:
svn propedit svn:ignore <directory>
To set the svn:ignore property non-interactively, first create a
file containing the value:
echo "*.tmp.html" > ignore.txt
echo "*OBJ*" >> ignore.txt
then use:
svn propset -F ignore.txt svn:ignore <directory>
List of mime-type:
C++ files (.cpp): text/x-c++src
C files (.c): text/x-csrc
DTD files (.dtd): text/xml-dtd
GIF files (.gif): image/gif
Header files (.h): text/x-chdr
HTML files (.html): text/html
JPEG files (.jpg): image/jpeg
Makefiles: text/x-makefile
PNG files (.png): image/png
Python files (.py): text/x-python
Shell scripts (.sh): text/x-sh
Text files (.txt): text/plain
XML files (.xml): text/xml
(please update the list...)
For your convenience use the tools/module_svn_propset.sh script.
30. Use doxygen style for source code documentation. It is required
for GRASS libraries, but also recommended for GRASS modules.
Do not use structural command inside documentation block since it
leads to some duplication of information (e.g. do not use \fn
command in comment blocks). The exception is \file command for
documenting a file, in this case structural command is required.
For files
/*!
\file snap.c
\brief Vector library - Clean vector map (snap lines)
(C) 2001-2008 by the GRASS Development Team
This program is free software under the GNU General Public
License (>=v2). Read the file COPYING that comes with GRASS
for details.
\author Radim Blazek
*/
For functions
/*!
\brief Snap lines in vector map to existing vertex in threshold
For details see Vect_snap_lines_list()
\param Map pointer to input vector map
\param type filter features of given type to be snap
\param thresh threshold value for snapping
\param[out] Err pointer to vector map where lines representing snap are written or NULL
\param[out] msgout file pointer where messages will be written or NULL
\return 1
*/
31. If you need to add support for a different library in the 'configure' script,
you should first seek consent in the grass-dev mailing list (see below), then
you need to expand 'configure.in' and run subsequently autoconf-2.13 (later
versions will not work) to re-generate 'configure'.
32. Tell the other developers about the new code using the following e-mail:
grass-dev@lists.osgeo.org
To subscribe to this mailing list, see
http://lists.osgeo.org/mailman/listinfo/grass-dev
33. In case of questions feel free to contact the developers at the above
mailing list.
http://grass.osgeo.org/development/
...
[please add further hints if required]
"Your attention to detail is appreciated."
See http://trac.osgeo.org/grass/wiki/Submitting

124
SUBMITTING_DOCS
View File

@ -1,124 +0,0 @@
NOTE: Please improve this list!
Dear (new) GRASS GIS Developer,
When submitting documentation to GRASS SVN repository, please take
care of following rules:
[ see SUBMITTING for C hints ]
[ see SUBMITTING_WXGUI for wxPython GUI code hints ]
[ see SUBMITTING_PYTHON for Python code hints ]
0. Introduction
There are two types of documentation
- Libraries programmers docs: we use doxygen and document the functions
directly in the source code. See lib/gis/*.c and lib/gis/gislib.dox for examples
- User manual: we write it in simple HTML, storing the manual in a
file '<module>.html' within the subdirectory of the module.
The file contains no header nor footer. The complete HTML file is
autogenerated during the compilation process (indeed, it is generated
in a virtual session directly after compilation of the module).
In this virtual session the module is called internally with
--html-description which generates the parameters/flags list in
HTML format, along with '<module>.html', HTML header and footer
the final HTML manual page is created and stored in the target
binaries directory. In a separate process the MAN format is
generated from the complete HTML files.
1. Editing of HTML pages
To avoid insertion of too complicated HTML tags (see also below),
we strongly suggest to use a plain text editor rather than a
HTML editor for editing.
2. Module manual page:
Place the documentation in HTML format into '<module>.html', where
<module> is the name of the module. E.g. if the module is named
r.example, the documentation file should be named r.example.html.
The easiest way to do this is to study an existing HTML page
(to get the page style, e.g. vector/v.to.db/v.to.db.html).
With a few exceptions, header and footer are NOT allowed.
You can add figures (PNG format); the figure name prefix should be the
module name. See raster/r.terraflow/r.terraflow.html for an example.
A number of major sections should be present in each help page.
* = Required
! = Suggested
. = Optional
In recommended order
--------------------
* <h2>DESCRIPTION</h2>
! <h2>NOTE</H2>, <h2>NOTES</h2>
! <h2>EXAMPLE</h2>, <h2>EXAMPLES</h2>
. <h2>TODO</h2>
. <h2>BUGS</h2>
. <h2>REFERENCE</h2>, <h2>REFERENCES</h2>
* <h2>SEE ALSO</h2>
* <h2>AUTHOR</h2>, <h2>AUTHORS</h2>
Note that the parameter information is auto-generated upon
compilation. This is done by running the module in a virtual session
after compilation (see the output of 'make'). To subsequently
verify the final HTML page, check the resulting HTML pages which
will be stored with the name of the module.
Examples (please add some) should be coded like this:
<div class="code"><pre>
v.to.db map=soils type=area option=area column=area_size unit=h
</pre></div>
The online WWW man pages is updated every Saturday (from SVN
repository).
3. Usage of limited HTML tags
Since the MAN conversion of g.html2man is limited, please use
no other HTML tags than:
<a> <b> <body> <br> <code> <dd> <dl> <dt> <em>
<h2> <h3> <h4> <head> <hr> <i> <img> <li> <ol> <p>
<pre> <sup> <table> <td> <th> <title> <tr> <ul>
Note that all tags has a closing tag except for <hr/>, <br/> and <p>.
Use lower case forms.
(The MAN converter is here: tools/g.html2man/)
4. Suggested HTML markup protocol:
Module names (i.e., v.category) should be emphsized with <em>,
and boldface <b> for flags and parameter names. Shell commands,
names, values, etc. should use <tt>. Empahsized phrases should use
italics <i>. The SEE ALSO section of each page should also be
alphabetized.
5. When submitting new files to the repository set SVN properties,
e.g. for HTML file
svn:mime-type : text/html
svn:keywords : Author Date Id
svn:eol-style : native
See
http://svnbook.red-bean.com/en/1.4/svn.advanced.props.html
You can also simply use this script:
http://svn.osgeo.org/grass/grass-addons/tools/module_svn_propset.sh
6. Compress PNG images with
optipng -o5 file.png
7. See also
http://grass.osgeo.org/wiki/Updating_GRASS_Documentation
...
[please add further hints if required]
"Your attention to detail is appreciated."

180
SUBMITTING_PYTHON
View File

@ -1,180 +0,0 @@
NOTE: Please improve this list!
Dear (new) GRASS developer,
when submitting Python code to GRASS SVN repository, please take
care of following rules:
[ see SUBMITTING for C hints ]
[ see SUBMITTING_WXGUI for wxPython GUI code hints ]
[ see SUBMITTING_DOCS for documentation ]
See also http://www.python.org/dev/peps/pep-0008/
0. Indentation
As Python determines nesting based upon indentation, it isn't just
a stylistic issue.
Please use 4-space indentation (GNU Emacs python-mode default).
See also "Python Style Guide" by Guido van Rossum
http://www.python.org/doc/essays/styleguide.html
1. Instructions for the GRASS script parser can be found in the g.parser
module's help page.
http://grass.osgeo.org/grass70/manuals/g.parser.html
2. Use the directory structure to place your script appropriately into
the source tree
- scripts go into scripts/
Also add a Makefile and a <module>.html file into this directory.
See existing Python scripts for examples.
3. Add a header section to the script you submit and make sure you
include the copyright. The purpose section is meant to contain a
general over view of the code in the file to assist other
programmers that will need to make changes to your code. For this
purpose use Python Docstring, see
http://epydoc.sourceforge.net/docstrings.html
Example (fictitious header for a script called g.myscript):
"""
MODULE: g.myscript
AUTHOR(S): John Doe <email AT some domain>
PURPOSE: Describe your script here...
COPYRIGHT: (C) 2007 John Doe, and by the GRASS Development Team
This program is free software under the GNU General Public
License (>=v2). Read the file COPYING that comes with GRASS
for details.
"""
The copyright protects your rights according to GNU General Public
License (www.gnu.org).
You can easily autogenerate the header and parameters from an existing
module using the --script flag. Example:
d.rast --script
Just select an existing module which is close to your application to save
efforts.
4. We don't want the $ ID $ in source code any more as it causes problems
for the branches.
5. Create and use secure temporary files and directories. Use the
grass.tempfile() or grass.tempdir() functions to do this. e.g.
# setup temporary file
TMP = grass.tempfile()
if TMP is None:
grass.fatal("Unable to create temporary files")
6. Use grass.findfile() when there is a need to test if a map exists.
# test for input raster map
result = grass.find_file(name = map_name, element = 'cell', quiet = True)
if not result['file']
grass.fatal("Raster map <%s> not found" % map_name)
# test for input vector map
result = grass.find_file(name = map_name, element = 'vector', quiet = True)
if not result['file']
grass.fatal("Vector map <%s> not found" % map_name)
... and so forth. See 'g.manual g.findfile' for details.
7. For any informational output, use the grass.message()
function. For error messages should be used grass.fatal_error() or
grass.error() and for warnings grass.warning(). For debugging
purposes grass.debug().
#normal message:
grass.message("Done")
# warning:
grass.warning("No input values found, using default values")
# error:
grass.error("No map found")
# fatal error:
grass.fatal_error("No map found, exiting")
# debug output (use g.gisenv to enable/disable)
grass.debug("Our calculated value is: %d" % value)
Try to omit any usage of the 'print' command for informational output.
8. PLEASE take the time to add comments throughout your code explaining what
the code is doing. It will save a HUGE amount of time and frustration for
other programmers that may have to change your code in the future.
9. Make sure a new line is at the end of each file.
10. For consistency, use README rather than README.txt for any README files.
11. Be sure to develop on top of the LATEST GRASS code (which is in SVN repository).
You can re-check before submission with 'svn diff':
Be sure to create unified ("diff -u") format. "Plain" diffs (the default
format) are risky, because they will apply without warning to code which
has been substantially changed; they are also harder to read than unified.
Such diffs should be made from the top-level directory, e.g.
"svn diff gui/wxpython/wxgui.py"; that way, the diff will
include the pathname rather than just "wxgui.py".
12. When submitting new files to the repository set SVN properties,
usually for directory
svn:ignore : *.pyc
or e.g. for Python file
svn:mime-type : text/python
svn:keywords : Author Date Id
svn:eol-style : native
svn propset svn:mime-type text/python new/file.py
svn propset svn:keywords "Author Date Id" new/file.py
svn propset svn:eol-style native new/file.py
See
http://svnbook.red-bean.com/en/1.4/svn.advanced.props.html
13. Tell the other developers about the new code using the following e-mail:
grass-dev@lists.osgeo.org
To subscribe to this mailing list, see
http://lists.osgeo.org/mailman/listinfo/grass-dev
14. In case of questions feel free to contact the developers at the above
mailing list.
http://grass.osgeo.org/development/
...
[please add further hints if required]
"Your attention to detail is appreciated."

160
SUBMITTING_WXGUI
View File

@ -1,160 +0,0 @@
NOTE: Please improve this list!
Dear (new) GRASS developer,
when submitting Python code to GRASS SVN repository, please take
care of following rules:
[ see SUBMITTING for C hints ]
[ see SUBMITTING_PYTHON for Python code hints ]
[ see SUBMITTING_DOCS for documentation ]
0. Introduction
For general GRASS, svn and Python issues and module related issues see
SUBMITTING_PYTHON and SUBMITTING.
GUI is divided into components. One component is usually placed in one
directory.
1. GRASS documentation
GRASS Programming manual for API and existing classes
http://grass.osgeo.org/programming7/wxpythonlib.html
GRASS wiki has pages about how to develop wxGUI
http://grasswiki.osgeo.org
GRASS Trac wiki has pages about the state of wxGUI development
http://trac.osgeo.org/grass/wiki/wxGUIDevelopment
2. External documentation
Style Guide for Python Code
http://www.python.org/dev/peps/pep-0008/
Python Style Guide by Guido van Rossum
http://www.python.org/doc/essays/styleguide.html
wxPython Style Guide
http://wiki.wxpython.org/wxPython_Style_Guide
Additional info on Python docstrings
http://epydoc.sourceforge.net/docstrings.html
3. Remember that functionality such as generating plots should be primarily
provided by modules not GUI.
4. Try to create create also g.gui.* module for the new GUI component. It helps
advanced users to access functionality and developers to test it. Moreover,
it helps to keep components separated and thus, supports re-usability.
5. Add a header section to each file you submit and make sure you
include the copyright. The purpose section is meant to contain a
general over view of the code in the file to assist other
programmers that will need to make changes to your code. For this
purpose use Python docstring.
The copyright protects your rights according to GNU General Public
License (www.gnu.org).
Please use the following docstring template:
"""!
@package dir.example
@brief Short example package description
Classes:
- example::ExampleClass
(C) 2012 by the GRASS Development Team
This program is free software under the GNU General Public License
(>=v2). Read the file COPYING that comes with GRASS for details.
@author First Author <first somewhere.com>
@author Second Author <second somewhere.com>
@author Some Other <third somewhere.com> (some particular change)
"""
6. Comment your classes and functions with docstrings. Use Doxygen syntax,
particularly, use commands which begins with @
(www.doxygen.org/manual/commands.html).
Comment also the code itself such as the meaning of variables,
conditions etc.
7. Make sure a new line is at the end of each file. Non empty line breaks the
build process.
8. Basic rules
Do not use print command unless you know what are you doing.
Use named parameters in functions (without space around '='), e.g.
dlg = wx.FileDialog(parent=self, message=_("Choose file to save current workspace"),
wildcard=_("GRASS Workspace File (*.gxw)|*.gxw"), style=wx.FD_SAVE)
instead of
dlg = wx.FileDialog(self, _("Choose file to save current workspace"),
_("GRASS Workspace File (*.gxw)|*.gxw"), wx.FD_SAVE)
Use wx.ID_ANY instead of `-1`.
Use GError, GWarning and GMessage instead of wx.MessageBox()
Do not use grass.run_command() or grass.read_command(). Use functions and
classes which uses threads such as RunCommand.
Use full strings, e.g.
if ...:
win.SetLabel(_('Name for new 3D raster map to create'))
else:
win.SetLabel(_('Name for new raster map to create'))
instead of
_('Name for new %s to create') % maplabel
where `maplabel` can be 'raster map' or '3D raster map'
When using AddGrowableCol/AddGrowableRow with sizers, put it after
adding widgets into the sizer, not just after creating of the sizer
(needed for wxPython >= 2.9).
9. Use tools such as pylint and pep8 to check your code (both style and
correctness). Just note that default settings of these tools is not fully
compatible with wxGUI/wxPython style and that some of the reported errors
may not apply to your code.
14. Tell the other developers about the new code using the following e-mail:
grass-dev@lists.osgeo.org
To subscribe to this mailing list, see
http://lists.osgeo.org/mailman/listinfo/grass-dev
15. In case of questions feel free to contact the other developers at the above
mailing list.
http://grass.osgeo.org/development/
[please add further hints if required]
"Your attention to detail is appreciated."