Some programs have too many options to list; in which case just list the most common ones and indicate 
      that there are more

All applications should provide a basic usage when passed the -help option. This is handled by EntryPoint so applications don't have to do anything except implement the usage() method.

void initDefaultVals()

- Set all class variables to default values

void initOptions(String[])

- Process command line options

void initVariables(String[])

- Any additional setup that is required after processing command line args

void execute(data.OutputManager)

- Runs the executable and passes output to the OutputManager

Executables must also provide a String usage() method, which returns basic information on how to run the application. This method is called by EntryPoint only if the command is run with -help and no other options.

EntryPoint simply constructs an AppName object, forwards the command line arguments, and then calls its execute method - unless the command is called with -help.

    Detailed description of what the program does

    Complete listing of options with explanation of their syntax and function

    Who wrote the program or a substantial portion thereof

    Other programs of interest

    Formerly bugs, but more general. Includes known bugs, limitations, or common misconceptions

The HTML man pages are auto-generated nightly - but new man pages need to be added to the Wiki. If you commit a new command, update the Wiki command list to point to the HTML version of that man page.

Man pages are written in NROFF. Check how your man pages look when you type man <command>. The man pages should follow a consistent format:

NAME
      program - One or two sentence description of what the program does

SYNOPSIS

      program -mandatoryOption <arg> [-notMandatory <arg>] [...]

      Some programs have too many options to list; in which case just list the most common ones and indicate that there are more

EXAMPLES
 Some common examples with a brief explanation

DESCRIPTION
  Detailed description of what the program does

OTHER SECTIONS  AS NECESSARY

OPTIONS
  Complete listing of options with explanation of their syntax and function

AUTHORS
   Who wrote the program or a substantial portion thereof

SEE ALSO
  Other programs of interest

CAVEATS 
  Formerly bugs, but more general. Includes known bugs, limitations, or common misconceptions

All applications should provide a basic usage when passed the -help option.

Other modules are arranged by theme. These classes should not have main methods (a couple currently do, eg AnalyzeHeader / Nifti1Dataset), they should be objects with a well-defined and documented API. We don't have well-defined coding standards, but Effective Java by Bloch has some good guideines.

Applications should be documented with command-line usage, man pages, and online tutorials as appropriate. All classes should be documented with Javadoc for all methods.

By default, public, package and protected methods will appear in the javadoc. Private methods should be documented in the code with a Javadoc comment, but this is more for the benefit of people coding the class itself.

You can build the Javadoc with make docs. See the Javadoc tutorial for more information on coding doc comments.

All applications

Camino users interact with the commands in the bin/ directory. These are executable files that may call one or more Camino program. Currently, most of the executables are bash scripts that do some simple system checks and then forward the application name and arguments to EntryPoint. New scripts should be written in bash, though we may allow other scripting languages later. Users never invoke Java or any other interpreter explicitly.

Apps have a special structure to accomodate Matlab wrapping and provide a consistent user interface. All applications should extend the Executable class. Executables provide the following methods, which are executed in the following order:

initDefaultVals()

- Set all class variables to default values

initOptions(String[])

- Process command line options

initVariables(String[])

- Any additional setup that is required after processing command line args

execute(data.OutputManager)

- Runs the executable and passes output to the OutputManager

Once you've written an app, you need to add it to the getExecutable method of the EntryPoint class, which is what actually gets executed in the script called by the user:

    java [options] EntryPoint AppName [options]

EntryPoint simply constructs an AppName object, forwards the command line arguments, and then calls its execute method.

Apps have a special structure to accomodate Matlab wrapping and provide a consistent user interface. All applications should extend the Executable class. Executables provide three methods:

initDefaultVals()

initOptions(String[])

execute(data.OutputManager)

Apps have a special structure to accomodate Matlab wrapping and provide a consistent user interface. All applications should extend the Executable class.

EntryPoint etc.

Javadoc

Usage

Man pages

Please see the test page for information about tests. Avoid embedding test code in the main methods of classes, or by writing test classes inside the packages themselves. For application tests, write a real-world use of the class and place it in ScriptTest. For unit tests, use the JUnit framework in the test directory. Java packages are virtual, you have the same access to package / protected methods in test/numerics as you do in numerics. A JUnit test is accessible to all users rather than just the person who wrote the test, and it can be run automatically by all users.

Camino users interact with the commands in the bin/ directory. These are executable files that may call one or more Camino program. Currently, most of the executables are bash scripts that do some simple system checks and then forward the arguments to a Camino command. New scripts should be written in bash, though we may allow other scripting languages later. Users never invoke Java or any other interpreter explicitly.

The code itself is written in Java and should adhere to the principles of object-oriented design.

Apps

Other modules are arranged by theme

Compilation is performed via a Makefile. Each class in apps is compiled individually, which should in turn compile the rest of the code. However, this relies heavily on Java to correctly work out all the dependencies with other classes, which it doesn't always do correctly. You can bypass this issue with make allclasses, which will compile everything under the Camino tree that isn't in the test directory. Alternatively, you can do make clean and then make, which should be equivalent, but this is slower. However, most users will download the code and just do make, so be sure that your apps all work by doing make clean, make, and then running the tests.

Please see the test page for information about tests. Avoid embedding test code in the main methods of classes, or by writing test classes inside the packages themselves. For application tests, write a real-world use of the class and place it in ScriptTest. For unit tests, use the JUnit framework in the test directory. Java packages are virtual, you have the same access to package / protected methods in test/numerics as you do in numerics. A JUnit test is accessible to all users rather than just the person who wrote the test, and it can be run automatically by all users.

Camino users interact with the commands in the bin/ directory. These are executable files that may call one or more Camino program. Currently, most of the executables are bash scripts that do some simple system checks and then forward the arguments to a Camino command. New scripts should be written in bash, though we may allow other scripting languages later.

Other modules

Compilation is performed via a Makefile. Each class in apps is compiled individually, which should in turn compile the rest of the code. However, this relies heavily on Java to correctly work out all the dependencies with other classes, which it doesn't always do correctly. Therefore, there is an additional target allclasses - make allclasses will compile everything under the Camino tree that isn't in the test directory.

Alternatively, you can do make clean and then make, which should be equivalent, but this is slower. However, most users will download the code and just do make, so be sure that your apps all work by doing make clean, make, and then running the tests.

Please see the test page for information about tests. Avoid embedding test code in the main methods of classes, or by writing test classes inside the packages themselves. Java packages

Compiling

Camino users interact with the commands in the bin/ directory. These are executable files that may call one or more Camino program. Currently, most of the executables are bash scripts that do some simple system checks and then forward the arguments to a Camino command. New scripts should be written in bash, though we may allow other scripting languages later.

Documentation

Testing

Do not embed testing code in the main

Camino code organization and standards

This page describes in detail how Camino code is (or should be - work in progress) organized.

The user interface

Camino users interact with the commands in the bin/ directory. These are executable files that may call one or more Camino program. Currently, most of the executables are bash scripts that do some simple system checks and then forward the arguments to a Camino command.

Applications (apps)

Documentation