Best way to share code within laboratory

I work in an academic research laboratory. Many of the PIs and RAs within the lab write a fair amount of Matlab code. I am trying to come up with a good way to make sharing our code with each other easier.

For example, say I write a function that I think someone else may find useful someday. It would be nice to stick that code in a centralized place for others to find. I envision that over time, this place becomes a database of many useful functions and scripts. Basically, it would become similar to an in-house MATLAB toolbox.

It would be great if this database were searchable, easy to navigate, and low maintenance such that as students/researchers come and go, the database remains useful for new people.

I've thought of a few ways to implement this. 1) Shared folder on a network drive. 2) Dropbox 3) Wiki/Website 4) Webtool such as Blackboard or Sakai.

Has anyone set up something similar to this within their respective organizations? If so, I would love to get your opinion on the best way to move forward. Any insights or thoughts about this topic are welcome.

Regards, Justin

[Justin Solomon]

Thanks everyone for the detailed and thoughtful answers. I think we'll probably go with simplicity and just used a shared network drive and enforce strict naming conventions with a common prefix, author initials, and version numbers, along with detailed file headers.

Answer 1

[Matt Fig]

We all use a shared network drive that is added to the path on everyone's MATLAB. Every function in the shared drive has a common prefix so that we know that the function is a shared one and also so that none of the shared functions inadvertently masks a local user's function. This system works pretty well.

[Jan]

Does "common prefix" mean something like "qwe_Plot"?

[Matt Fig]

Yep.

Answer 2

[Jan]

Of course a network folder containing the M-files is very useful due to its simplicity. Matlab's LOOKFOR, HELP and DOC command helps to keep the overview in a way Matlab users are familiar with already.

It will be far more complicated to maintain the code: What happens if somebody developed a function under Matlab 6.5, leaves the company and some of the functions are not supported by modern Matlab versions anymore? You cannot remove the function, because you do not know who is using it. You cannot update the function in general, because replacing outdated commands by new ones cannot be guaranteed to have the exactly same behavior.

Therefore you need a standardized and really exhaustive documentation for each function. To get a rough overview to the occurring problems, download 20 arbitrary submissions from the FEX and try to run them. Then select 20 files from the 50 contributors with the highest ratings. Even in the later case you will fail.

Standard solutions to handle (not solve) such problems:

• Exhaustive help texts
• Check size and type of inputs
• NaNs and empty inputs must be handled
• Errors must be caught
• A function must contain the name of the author, a date, a version information, a list of operating systems and Matlab versions the function has been tested in
• Each function must be accompanied by a unit-test: The advertised behavior is tested by known-answer-tests, random input data are used as penetration test. Caller must rely only on the features, which are included in the unit-test. Example: Matlab recently changed the reply of STRNCMP with empty inputs and in "n" is larger than the sizes of the input strings (a rare case of undocumented changes of a core function - ugly!). If any function relied on the former behavior, it will crash now. But neither the old nor the new behavior is explained in the documentation.
• The code must be documented massively.
• Care about a clear and legal license. Under which condition is it allowed to share code of others in a collaboration with an external partner? This is not trivial. Imagine that a university can have the policy not to collaborate with military projects. But who will decide if a clinical study with injured soldiers has a military nature?! Engage a lawyer before the troubles occur.
• A version control is obligatory.

Answer 3

[Joseph Areeda]

I agree it's not a trivial problem.

We use an svn repository, others in our collaboration use git. IMHO the differences are not worth the bandwidth used to argue about it.

And we use more than one flavor of Wiki to describe the code. Those differences are even less worthy of bandwidth.

I wish there was something similar to Javadoc that would go through a directory tree and produce html of all the documentation.

Matlab's Publish function is pretty cool but I haven't figured out how to do it on "everything".

Joe

Answer 4

[Oliver Woodford]

We use a version controlled repository, stored on a central server.

[Image Analyst]

Same with us. I don't have a path to the server version though, like Matt does. I keep a local copy on my hard drive and have a path to my local copy. Every once in a while I update my local copy from the repository.

[Oliver Woodford]

Same here.