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

Depending on the situation it can be easier to use a procedural or object oriented programming (OOP) paradigm. Procedural classes provide static functions which can be invoked directly while OOP requires a class to be declared first. When it makes sense BoofCV provides both types of interfaces.

Applying Gaussian blur using a procedural interface:

BlurImageOps.gaussian(input,output,-1,3,storage);

Apply Gaussian blur using an OOP interface:

BlurFilter<ImageFloat32> filter = FactoryBlurFilter.gaussian(ImageFloat32.class,-1,3);
filter.process(input,output);

In BoofCV the procedural interface often allows the user more control over memory management while the OOP interface handles memory management internally. Having more control is useful when highly optimizing code, but if you are just experimenting then letting the library handle the details is desirable.

Java Generics

Computer vision requires mixing together and working with a wide variety of different image formats. This can lead to frusteration where if the wrong type of image is provided it might not be detected at runtime. To get around this issue [Java generics] are used extensively throughout the code base to provide stronger type checking. There are also situations when using them can be annoying or excessively verbose, in which case one can simply choose not to use them.

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.
*Ops	Functional programming interface to a set of operations. Often easier to use than their object oriented equivalents. Strong type checking is provided at compile time.
G*Ops	Generalized version of functions provided in the corresponding *Ops class. Weaker type checking is provided but much easier to use if Java Generics are being employed.
_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.

Coding Standards

Contents