D.4 General Guidelines

All Octave’s sources are distributed under the GNU General Public License (GPL). Currently, Octave uses GPL version 3. For details about this license, see http://www.gnu.org/licenses/gpl.html. Therefore, whenever you create a new source file, it should have the following comment header (use appropriate year, name and comment marks):

## Copyright (C) 1996-2015 John W. Eaton <jwe@octave.org>
##
## This file is part of Octave.
##
## Octave is free software; you can redistribute it and/or modify it
## under the terms of the GNU General Public License as published by
## the Free Software Foundation; either version 3 of the License, or
## (at your option) any later version.
##
## Octave is distributed in the hope that it will be useful, but
## WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with Octave; see the file COPYING.  If not,
## see <http://www.gnu.org/licenses/>.

Always include commit messages in changesets. After making your source changes, record and briefly describe the changes in your commit message. You should have previously configured your .hgrc (or Mercurial.ini on Windows) with your name and email, which will be automatically added to your commit message. Your commit message should have a brief one-line explanation of what the commit does. If you are patching a bug, this one-line explanation should mention the bug number at the end. If your change is small and only touches one file then this is typically sufficient. If you are modifying several files, or several parts of one file, you should enumerate your changes roughly following the GNU coding standards for changelogs, as in the following example:

look for methods before constructors

* symtab.cc (symbol_table::fcn_info::fcn_info_rep::find):
Look for class methods before constructors, contrary to MATLAB
documentation.

* test/ctor-vs-method: New directory of test classes.
* test/test_ctor_vs_method.m: New file.
* test/Makefile.am: Include ctor-vs-method/module.mk.
(FCN_FILES): Include test_ctor_vs_method.m in the list.

In this example, the names of the file changed is listed first, and in parentheses the name of the function in that file that was modified. There is no need to mention the function for m-files that only contain one function. The commit message should describe what was changed, not why it was changed. Any explanation for why a change is needed should appear as comments in the code, particularly if there is something that might not be obvious to someone reading it later.

When submitting code which addresses a known bug on the Octave bug tracker (http://bugs.octave.org), please add ’(bug #XXXXX)’ to the first line of the commit messages. For example:

Fix bug for complex input for gradient (bug #34292).

The preferred comment mark for places that may need further attention is FIXME:.