%% checklist: functions

%% naming
% A function usually DOES something, so that it starts with a lower case 
%   verb, like configElk. If routines are different, based on the input 
%   variable type, it should end with the upper case letters of the type,
%   like moveHrep(). Further descriptions of a function are added with 
%   upper case starting words between this first and last word, like:
%   addMinkowskiVrep or computeMeasureDec. The naming pattern is known as
%   lower camel case.
%
% Check, if a function already exists in MATLAB namespace. For example, 
%   'move' already exists so that moveVrep had been chosen.

%% documentation
% The first line contains a short description of the functionality. It must
%   remain a single line, because of internal things that MATLAB does with
%   the very first line.
%
% The syntax follows the first line with the most common syntax, including
%   output variables. Optional arguments are not provided.
%
% The following paragraphs explain the function and have to explain every
%   variable name that is provided in the syntax. If literature references
%   exist, they should be provided, here.
%
% Optional arguments are described in the following paragraphs.
%
% The last lines contain 'See also:' and related function names. A good
%   practise is to list functions that generate the input variables. Other
%   candidates are: functions that perform the same task with a different 
%   input type (hrep/vrep); functions that perform the same level of
%   operation (move, stretch, rotate).
%
% It follows an empty line to prevent 'help function' from plotting the
%   following parts.
%
% The copyright note is obligatory and required in all functions.
%
% The remaining part of the documentation should be sufficient to quickly
%   identify the parts of operations. Use '%%' for code blocks.

%% testing
% extensive unit testing is required for all functions on the basic level.
%   Code coverage should be almost complete. Only exception handling for
%   cases that cannot happen (in theory) might be omited, like:
%     a = rand
%     if a >= 0 && a < 0.5
%       some code;
%     elseif a >= 0.5 && a <= 1
%       some code;
%     else
%       error('elk:layerDummy:numericalError', ...
%             'rand is not in [0, 1], this should not happen')
%   end
%
% Unit testing is optional on all higher levels. However, core algorithms
%   must be tested with a case study on the application layer. The results
%   of the application layer should be regularly checked. They might be
%   checked in short periods for errors and long periods for plausibility
%   including a comparison to the original results.
%
% The application layer is not tested. It is usually closed and verified
%   with the corresponding publication.


% Variable names should be descriptive. Short names, like 'x' are almost
%   never sufficiently descriptive. The plural usually adresses Lists,
%   Vectors, Matrices or Structures. To avoid ambigeousities, there is no
%   plural in variable naming! A list (cell-array) of results might be
%   called 'resultList'.
%
%
% The developement tool parseTags is used to keep track of TODO items or 
%   important internal comments (INFO).

% HAVE FUN!