File Exchange

image thumbnail


version (1.33 MB) by Massimo Ciacci
Search all unreachable code files, from one or more Main Entry files, and delete them.


Updated 08 May 2018

View License

Search all unreachable code files, from a Main Entry file (or multiple entry files), and delete them.
Do you happen to have a large Matlab project with few entry points (MAIN1,MAIN2,..) ? Then there is a chance that a lot of scripts within your root are not needed by none of those entry points. This tool helps you clean up your code before releasing it.
Note: Dependencies in this script are very conservative by design: A calls B if the string "B" is mentioned anywhere in A.
More specifically
functioName1/scriptName1 is considered Reachable from MAIN.m if the string functioName1/scriptName1 appears in MAIN.m. This is extended recursively to all depth of "calls".
KILLORPHANFILES() starts-up a number of user dialogues consisting of these steps
- select MAIN file
- select ROOT folder
- LIST all MAIN-unreachable files in ROOT
- SELECT which ones / CONFIRM deletion
% - A list of all filenames within root is created,
% with MAIN1,MAIN2,.. in position 1,2,...
% - Make dependency table:
% A(i,j) = "name(j) appears in file(i)" (even within a comment)
% this way also commented code is protected (desired)
% - Propagate dependency (transitive closure of adjacency matrix A)
% If i mentions(needs) j and j mentions k then i needs k:
% i --> j --> k ==> i --> k
% A(i,j)==1
% A(j,k)==1 ==> A(i,k) = 1
% - A(1,:) contains all nodes called by MAIN1 within selected ROOT folder.
% - A(2,:) contains all nodes called by MAIN2 within selected ROOT folder.
% - Intersection of {~A(1,:),~A(2,:)} is the unreachable set
% by the union of MAIN1,MAIN2. Meaning both MAIN1,MAIN2 will run after
% clean up is completed

Cite As

Massimo Ciacci (2020). killOrphanFiles() (, MATLAB Central File Exchange. Retrieved .

Comments and Ratings (5)

Thanks Carl for the tip, I like your suggestion, it makes it safer indeed. It is now implemented that way.

I strongly recommend you modify the code so that the orphaned files are moved to an "archive" directory rather than being deleted. People make mistakes, or maybe an orphan function will turn out to be useful elsewhere.

After looking around, i still think that a potential call considered to be a call is not a problem but rather a feature, given the task of this function: clean up unnecessary files, before releasing a trunk. Better to be safe and delete one file less. I found myself using this quite often since its submission, and i chose not to change it. After all there are true and good code dependency tools out there; for those who need that they are here in the wrong place.

Thanks Jan for your comment.

I must add that i did it intentionally to treat names as function calls even within strings, since often i have commented code which i may want to uncomment, and so that for me is a dependency. And despite this it still reduced one of my trunks from 1500 m files to less than 500, but yes it was not well organized to say the least:).

On the other hand it should be definitely chosen by the user whether commented calls should be ignored. I will look into this as soon as i can. Thanks


The called functions are recognized by a simple search of the file name in the complete code. Even names appearing in strings or comments are treated as a call.
Although this is mentioned in the help section, it concerns the core job of this function. Therefore this function is of limited use. The nicest graphics are not useful, when the shown contents is not determined sufficiently.

You find several submissions to obtain a list of dependent functions reliably.


- Following suggestion from Carl Witthoft, files are now moved to a folder called "__Orphans" created inside the user selected root folder. It is up to the user to actually delete the files.

User can now choose to ignore comments (a commented call is not a call). Ignoring comments deletes more orphans.
Should work also in 2011b, the new version was tested on 2015b.

Improved functionality, to support multiple entry points.

Changed screenshot to a less distracting one.

- Updated description about the weak definition of 'dependency'. Note however that this method will not miss any true dependency to the best of my knowledge. And it does not require special code toolboxes either.

- Added info in help section
- Added plots of graphs before and after pruning.

Added more info in summary

changed few strings

MATLAB Release Compatibility
Created with R2015b
Compatible with any release
Platform Compatibility
Windows macOS Linux
Tags Add Tags