MUMPS level of flexibility allows developers to write very compact expressions, that can sometimes be difficult to read for others. It is therefore convenient to have at hand a code re-formatting tool capable of re-writting M expressions in a more verbose and human-readable format.

Joel Ivey has developed and kindly shared this kind of tools at.


The XTMREDO.m routine in the CodeFormatter directory is the central piece of the tool.

This routine, will take another M routine as argument. It will parse it, and produce as output a reformatted version of the routine written in a more verbose and human-readable style.


This code has been included in the most recent release of the Virtual Machine.



In this particular case, the files have been installed in "~/src/" and the routines have been linked to the VistA installation by using symbolic links to the directory "~/Downloads/VistA/r"


From inside GTM, the routine can be executed as


E.g. to refomat the code of the "XINDEX.m" routine, and generate an output in the new file "ZZ111127XINDEX.m", where "111127" is the date in which the XTMREDO routine is being executed.

Just to give an illustrative example,

The input code:

 S ARG=$E(LIN,1,I-1) S:CH=" " I=I+1 S LIN=$E(LIN,I,999) Q


Will be reformatted as:


SEP    FOR I=1:1 QUIT:$$DOFOR1()
    SET:CH=" " I=I+1

DOFOR1()    ;
    QUIT:" "[CH 1
    QUIT 0

This code formatting tool also helps to illuminate the question:


  • "How many lines of code are there in VistA?"

In this particular case, the XINDEX.m file, with 144 lines of code gets to be expanded to 327 lines of code: a 2.27 Factor.

If we naively apply this same proportion to the total number of lines of code currently in the VistA FOIA release, we get:

Number of lines of code in current VistA - FOIA = 2.5 Million

Estimated number of lines for expanded code = 2.5 Million * 2.27 = 5.6 Million

This is, of course, only a back-of-the-envelope estimation.

A proper measure should be computed by running XTMREDO in all the routines in the VistA FOIA release and then adding up the total number of lines of code in the reformatted routines.

Number of lines of code, certainly does not tell the entire story on the level of complexity of the code, but at least give a first sense of the size of the community that will be required to maintain a healthy ecosystem for the Open Source EHR.

A good source of references between number of developers and code base size for open source projects can be found in


Of course, comparing number of lines of code between projects is subject to the bias of the particular differences between language, and the coding style practices adopted by every project. All these comparisons, must therefore be taken with a grain (or two) of salt, and be put in perspective.