get used lines project matlab

Hello everybody,

I have a very big project in Matlab with a lot of functions and dependencies and my purpose is to try to simplify it the more as I can because I only want to execute and debug part of the project(but still should remain about 2000-3000 executed code lines!).

To achieve this and make mi live easier I would like to find a way to get the used code inside the project to be able at first unwrap all code to a only one script with the executed code. I want this also because the code pass a shared structure between functions for variables and configuration that I want to remove and leave just the configuration and variables and the beginning of the script.

the first attempt was to use the profile function to see the dependencies and used functions and extract the used code with the profile('info') command but I realized that after made my own functions to extract the used code for each one function inside my project the profiler doesn't take in account the end command and this make my code unusable and impossible to go file by file to see what's happening.

Another way was to try to debug the code line by line and run some kind of script inside the debugger to extract the evaluated lines but for me this was impossible due restrictions in debugger for running scripts and code with dbstep function and also a nightmare of levels and dependencies.

Any ideas?.

Thanks, regards.

Answer 1

[Jan]

 make mi live easier I would like to [...] unwrap all code to a only one script

This would make the debugging much harder. It is a really bad idea to debug or maintain a changed code, because it does not allow to draw reliable conclusions about the real code. Packing many functions into one big script produces a huge block of code, which will be less readable and has the severe problem, that the changes of variables in scripts interfere with the rest of the code. Therefore it is recommended to strictly avoid scripts in productive code.

A reliable programming technique is to store all code which is used as a "tool" in a separate function and check them using exhaustive unit-tests - see https://www.mathworks.com/help/matlab/matlab-unit-test-framework.html. Then a coverage report is possible also: https://www.mathworks.com/help/matlab/ref/matlab.unittest.plugins.codecoverageplugin-class.html. If the "tool"/sub-functions are tested to create the wanted results and handle bad input with the expected error messages, you can implement an "integration test", which tests the results of the main function.

This will leave the actual code untouched, such that you will work exactly with the same code, which have been tested. The automatic test routines allow to repeat the tests on other machines or Matlab versions also.

Fiddling with the profiler and modifying the existing code for a "collection in one script" will make your life much harder and does not help to improve or control the reliability of your code.

Any kind of "automatic" extraction of the used code is very susceptible for mistakes. See:

function main
a = 0;
for k = 1:100
  if rand > 0.000001
     a = a + subfcn(k);
  else
     a = -a;
  end
end
end

function b = subfcn(k)
a = k^3;
b = a + 5;
end

Then a function to determine the code-coverage might oversee the "a=-a" line. Combining the code into one single script would have the bad side-effect, that modifying "a" inside subfcn() would destroy the value of "a" in the main function. A reliable way to test this would be to examine the output of subfcn by a unit-test and a check for the plausibility of the result in the main function. Then you find some tools in the FileExchange, which collect all subfunctions, which occur in the code - independent from the fact, if they are called or not called for a specific set of inputs.

By the way, 3000 lines of code does not sound like a "very big project". As a rule of thumb a programmer can maintain 100'000 lines of code. At least at this level (but preferably from the very first lines already) methods of software engineering and project management are required to control the reliability.

[julims]

Thanks for reply Jan Simon, you are right the one script idea has they own problems and could give errors with recursive and repeatable functions.

The point of unwrap the code is because I want to translate it to another platforms and for this reason I think I have to change the structure for a better understanding. I will give a try to the links you provide me.

regarding the 3000 lines is an estimation of the used code and for me handle with that is enough, I don't want to see how could be with 100.000 lines of codes(curious about where you get that).

Thanks again, regards.