Coding Standards

Coding Standards

One of the primary reasons Java was selected as a programming language for this library are the set of development tools available for Java. Less restrictive and structured languages such as C/C++ essentially allow the developer to redefine much of the language on the fly. While at first this sounds like a positive characteristic, it has hindered the ability to create development tools which allow refactoring and other modern techniques. BoofCV's API has been designed to take full advantage of integrated development environments (IDE) such as IntelliJ and Eclipse.

Unfortunately Java does not provide templates. For example, if two classes are identical in every respect except that they use different primitive data structures internally in Java you need to create to classes. In languages such as C++ you can create one template class. The later is easier to maintain and requires less code. To get around this issue auto code generation is extensively used throughout the library.

A common pitfall which developers fall into is over abstraction. This leads to code which is difficult to use or develop because of its complexity and layers of abstraction. Computer vision has many complex algorithms and competing ideologies on how to catalog these algorithms together. To mitigate this issue the code in BoofCV has been divided into algorithms and abstractions. Code inside of algorithms has minimal abstraction and is implemented in whichever way makes the most sense to that particular algorithm. Abstraction containers generalized interfaced and wrappers around the algorithms so that they fit that particular formalism. This also greatly reduces unnecessary dependencies between the code allowing pieces of BoofCV to be cut off and used independently.

PROCEDURAL VS OOP.

Packages

Each project module (e.g. image processing) has a standardized package structure.

Java Package	Description
boofcv.abst	Contains abstracted interfaces or wrappers for algorithms in the same family or to enforce different formalisms. Sometimes to conform to these algorithms performance or unique capabilities are lost but added flexibility is gained by making it easier to switch algorithms.
boofcv.alg	Bare algorithms which minimal abstraction. Using algorithms directly allows for greater performance and or for a developer to wrap inside their own interface/frame work.
boofcv.factory	Contains factories for creating raw algorithms or abstracted implementations of algorithms easily. Using a factory makes it easier to get started but the simplicity comes at the cost of flexibility. Flexibility is lost because factories hard code some parameters.

Directory Structure

Each project module also has a standardized directory structure.

Directory	Description
src/	Contains library source code.
test/	Contains unit tests for source code.
generate/	Source code for auto-generating source code in "src/". The package of the generator corresponds to the package the output should be placed inside.
benchmark/	Contains simple codes for testing runtime performance of different algorithms. Used during development to ensure efficiency.

Class Name Standards

The following standard prefixes and suffices are used throughout the code base.

name	Description
Impl*	Is a low level (often auto-generated image type specific) implementation of an algorithm. Directly accessing these class is rarely required and discouraged.
Wrap*	Wrapper around an algorithm for a specific interface. These classes are found inside the boofcv.abst package and its children.
Factory*	Factory for creating abstracted algorithms.
Factory*Alg	Factory for creating a raw algorithms.
*_F32, *_F64	Implementation for 32-bit/64-bit floating point images or data structures, respectively.
*_S32	Implementation for signed 32-bit integer images or data structures.
*_U16, *_S16	Implementation for unsigned/signed 16-bit integer images or data structures, respectively.
*_U8, *_S8	Implementation for unsigned/signed 8-bit integer images or data structures, respectively.