#code-reuse

The One Function Per M-File rule gets especially frustrating when extended to MEX, MATLAB's system for writing native code that exposes itself to interpreted MATLAB code. MEX wraps one of several C or Fortran compilers and compiles your code to a shared library called a MEX file. Each MEX file then can only expose exactly one name to the MATLAB interpreter.

Want two functions to be exposed? They must be in separate compilation units, and thus may not directly share state. This restriction makes it easier for the MATLAB interpreter to find your symbols by reducing the problem of resolving an unknown function name to that of finding a file with a given extension, but makes it very difficult to write code that shares resources in a sensible way.

Writing functions is a great way of keeping code organized and clean. The style that many languages encourage is to write lots of small functions, each of which has a clearly identifiable purpose and behaviour. MATLAB is not one of those languages.

Instead, each function that is visible to the rest of your code must be in a separate file, called an M-File. While you can declare multiple functions in an M-File, all but one such function is private to that file. This makes it difficult to quickly review groups of related functions and encourages the writing of longer functions. Moreover, it causes even the smallest of projects to be separated into many smaller source files, even when that obscures the organization and layout of the code.