Help info formatting

[coalsont]

A different type of question, what should the formatting be for help information?

First, matlab help info of built-in functions is generally summary first, then multiple function signatures (really, using different optional arguments) with explanations interspersed. The current cifti-matlab help has function signatures first (and includes the function keyword), and then the description immediately below that, then options, and examples (when present) at the bottom.

Examples:

>> help unique
 unique Set unique.
    C = unique(A) for the array A returns the same values as in A but with 
    no repetitions. C will be sorted.    

    C = unique(A,'rows') for the matrix A returns the unique rows of A.
    The rows of the matrix C will be in sorted order.
...
>> help cifti_read
 function outstruct = cifti_read(filename, ...)
    Read a cifti file.
    If wb_command is not on your PATH and you need to read cifti-1
    files, specify "..., 'wbcmd', '<wb_command with full path>'".

    >> cifti = read_cifti('91282_Greyordinates.dscalar.nii');
    >> cifti.cdata = outdata;
    >> cifti.diminfo{2} = cifti_diminfo_make_scalars(size(outdata, 2));
    >> write_cifti(cifti, 'ciftiout.dscalar.nii');

How closely do people want this to match matlab builtin help formatting and order?

optional inputs

Some of the functions (generally lower-level) still have optional arguments that don't use varargin, so if we don't change them to use varargin, how should the help info look? Some ideas:

1) like matlab multi-signature help info on zeros:

    %function outmap = cifti_diminfo_make_scalars(nummaps)
    %function outmap = cifti_diminfo_make_scalars(nummaps, namelist)
    %function outmap = cifti_diminfo_make_scalars(nummaps, namelist, metadatalist)

2) square brackets, like many command line utilities:

    %function outmap = cifti_diminfo_make_scalars(nummaps[, namelist, metadatalist])

3) no notation, and expect people to read the help down to where it says what is optional (this is what is currently implemented):

    %function outmap = cifti_diminfo_make_scalars(nummaps, namelist, metadatalist)
...
    %   Only the nummaps argument is required.

optional outputs

Some functions also have multiple outputs, and in matlab all outputs are automatically optional (a function can be coded to check the number of output arguments and manually throw an error, or even change its behavior, but there is no reason to do that here). Can we expect users to be aware of this, or do we need some notation for that also? Example:

    %function [outdata, outroi] = cifti_struct_dense_extract_surface_data(cifti, structure, dimension)

The help info for unique starts with the 4 combinations of single vs multi output, and single versus multiple arguments, but discontinues that method as soon as it reaches more advanced options. So, some options: 1) like matlab help info on unique, start with a few combinations, then any further optional arguments use only the all-outputs notation:

    %function outdata = cifti_struct_dense_extract_surface_data(cifti, structure)
    %function [outdata, outroi] = cifti_struct_dense_extract_surface_data(cifti, structure)
    %function outdata = cifti_struct_dense_extract_surface_data(cifti, structure, dimension)
    %function [outdata, outroi] = cifti_struct_dense_extract_surface_data(cifti, structure, dimension)
    %function [outdata, outroi] = cifti_struct_dense_extract_surface_data(cifti, structure, dimension, somefutureopt)

2) separate input and output sections:

    %function outdata = cifti_struct_dense_extract_surface_data(...)
    %function [outdata, outroi] = cifti_struct_dense_extract_surface_data(...)
    %function ... = cifti_struct_dense_extract_surface_data(cifti, structure[, dimension, somefutureopt])

3) just the full outputs notation, and expect users to know how to ignore outputs they don't need (this is what is currently implemented)