Coding practices to simplify complex functions

Hi,

i am working on some sound synthesis algorithms for a 3 months project, and I am looking to better structure my code. The basic function that generates a sound looks something like this :

function [out] = stiffString(f,duration,L,node,gamma,kappa,xe,sigma0,sigma1,fs)

There are a lot of parameters that are able to control the sound in some way, which are all passed as arguments. The problem is it makes the code very complex and hard to read, and I fear it will become even worse as the project goes on. I wanted to know what are the best practices to simplify a code like this.

[Dyuman Joshi]

The first thing I would suggest is to document everything properly. This answer by Chad Greene will give you a better idea about that - https://in.mathworks.com/matlabcentral/answers/228557-experts-of-matlab-how-did-you-learn-any-advice-for-beginner-intermediate-users#answer_185153

Secondly, making local or separate functions will help you in organising things in a structured manner, avoiding things from geting too complex or repetetive. You can see some concise points regarding this in this answer by Stephen23 - https://in.mathworks.com/matlabcentral/answers/228557-experts-of-matlab-how-did-you-learn-any-advice-for-beginner-intermediate-users#answer_185097

A similar answer from that particular thread I'd like to share is - https://in.mathworks.com/matlabcentral/answers/228557-experts-of-matlab-how-did-you-learn-any-advice-for-beginner-intermediate-users#answer_1257689

That thread, in general, is extremely helpful with constructive recommendations.

You will find similar points mentioned in MATLAB Documentation pages as well - https://in.mathworks.com/help/matlab/matlab_prog/techniques-for-improving-performance.html

[Martin]

Thanks a lot, that's exactly what I was looking for !

Answer 1

[Rik]

I would suggest using a struct (or Name,Value pairs) for functions with more than 4 inputs. The attached function allows parsing this kind of input to a struct. The function below can be used as a template to test the inputs and return a custom error message.

Neither is commented extensively, but you probably get the idea.

function [success,opts,ME]=##YourFunction##_parse_inputs(varargin)
% Parse the required and optional inputs to a struct. If anything fails, an ME struct will be
% created and the first output argument will be set to false.

success = false;
ReturnFlag = false;
ME = struct('identifier','','message','');

% Define the default. This can also happen in a separate function with a
% persistent variable so you don't have to initialize every time the
% function is called.
default = struct(...
    'f','',...
    'duration',10,...
    'L',false,...
    'node',SomeFunction(SomeInput));

[opts,replaced] = parse_NameValue(default,varargin{:});

if numel(replaced)==0,success = true;ME = [];return,end % no default values were changed

% Check optional inputs.
for k=1:numel(replaced)
    item = opts.(replaced{k});
    ME.identifier = ['##YourFunction##:incorrect_input_opt_' lower(replaced{k})];
    switch replaced{k}
        case 'f'
            if numel(item)==1 && iscellstr(item)
                % Sometimes you want to accept cellstr and string as input,
                % but it is nicer to be able to assume a char vector.
                item = char(item);
            end
            passed = SomeTest(item);
            if ~passed
                ME.message = 'f should be something specific';
                return
            end
            % If you (potentially) changed item, you need to overwrite
            % opts.
            opts.f = item;
    end
end

success = true;ME = [];
end