Implement all ML related code in the namespace ml, even the source code (please use macros ML_START_NAMESPACE and ML_END_NAMESPACE)!

Many ambiguities can be avoided and global namespace pollution is reduced.

Use mlDebug macros, or - if you really cannot avoid it - use std::cout and std::cerr! Never use (f)printf, cout or cerr from global namespace!

Otherwise, the debug output cannot be controlled or disabled. std::cout, std::cerr and mlDebug statements can be redirected and disabled by the ML. Forgotten outputs of ML modules (hundreds of them exist) can be disabled and do not lead to output garbage in ML based applications. See module RedirectStream in project MLStreamSupport if you want to redirect std::cout or std::cerr to the ML error handler.

Never use abort(), exit() or other program terminating commands!

The ML cannot handle those terminations. Use dedicated ML macros for error handling as described in Section 5.2, “Handling Errors”.

Avoid global image processing algorithms!

Avoid them, even if they are sometimes faster or easier to implement. Always remember that ML-based applications often use hundreds of modules and that just some modules that work with global approaches can easily lock the entire memory so that is impossible for the ML-based applications to run safely. The ML is dedicated to working safely with huge networks which, however, is only possible if programmers stick to the page-based image processing approach.

This is sometimes difficult, but see Chapter 4, Image Processing Concepts and Section 4.2.1, “Page-Based Concept”, Section 4.2.4, “Kernel-Based Concept” and Section 4.3.2, “Sequential Image Processing Concept” for detailed information on the page-based, kernel-based, and sequential image processing concepts as well as Section 2.3.7, “ VirtualVolume ” for information on the VirtualVolume class to find an adequate algorithm approach that does not need too much memory.

Document your module well, test it and optimize it!

Although this rule should be self-evident, it is seldom observed which often leads to big problems:

Always remember that especially MeVisLab applications often use hundreds of modules at once. This would not be possible with unstable modules.

See Section A.5, “How to Document an ML Module” and Appendix B, Optimizing Image Processing for a description of an adequate module documentation and for information on how to optimize modules.

Use the ML functionality for error handling and memory allocation!

Only the ML can avoid exceeding memory usage and undesired application crashes. See Section 5.2, “Handling Errors”, ConstructingAndDeletingObjects, HandlingExceptions, and Chapter 5, Debugging and Error Handling for more information.

Name field pointers in your modules as field pointers!

Name them, e.g., with the appendix "Fld" like "thresholdFld". That makes module code much easier to read.

Try to implement your algorithms for all 6 dimensions!

Programmers tend to forget that the ML supports fully 6D image processing and thus only implement 2D or 3D algorithms. Try to work high (6) dimensional algorithms; it is often easier than expected!

However, there are also algorithms which become quite difficult; try to support 6D by bypassing higher image coordinates; so a 2D algorithm, for example, would be implemented in such a way that it filters all slices of a 3D (or higher dimensional) image independently. Thus, also images of a higher dimension can benefit from those algorithms even if it works only in 2D.