Первая функция в m-файле (т.е. основная функция ) вызывается при вызове этого m-файла. не требуется , чтобы основная функция имела то же имя, что и m-файл, но для ясности должно . Если функция и имя файла различаются, для вызова основной функции необходимо использовать имя файла .
Все последующие функции в m-файле, называемые локальными функциями (или «подфункциями» в более старой терминологии), могут вызываться только основной функцией и другими локальными функциями в этом m-файле. Функции в других m-файлах не могут вызывать их. Начиная с R2016b, вы также можете добавлять локальные функции в сценарии , хотя поведение области действия остается прежним (то есть они могут вызываться только из сценария).
Кроме того, вы можете также объявить функции в других функциях. Они называются вложенными функциями , и их можно вызывать только из той функции, в которую они вложены. Они также могут иметь доступ к переменным в функциях, в которые они вложены, что делает их весьма полезными, хотя и немного сложными для работы.
Больше пищи для размышлений ...
Есть несколько способов обойти обычное поведение области видимости, описанное выше, например, передача дескрипторов функций в качестве выходных аргументов, как упоминалось в ответах от SCFrench и Jonas (что, начиная с R2013b, облегчается функцией localfunctions
). Однако я бы не советовал прибегать к таким уловкам, так как, вероятно, есть гораздо лучшие варианты для организации ваших функций и файлов.
Например, допустим, у вас есть основная функция A
в m-файле A.m
вместе с локальными функциями D
, E
и F
. Теперь предположим, что у вас есть две другие связанные функции B
и C
в m-файлах B.m
и C.m
, соответственно, которые вы также хотите иметь возможность вызывать D
, E
и F
. Вот несколько вариантов, которые у вас есть:
Поместите D
, E
и F
каждый в свои отдельные m-файлы, что позволяет любой другой функции вызывать их. Недостатком является то, что область действия этих функций велика и не ограничивается только A
, B
и C
, но плюс в том, что это довольно просто.
Создайте defineMyFunctions
m-файл (как в примере с Jonas) с D
, E
и F
в качестве локальных функций и главной функции, которая просто возвращает им дескрипторы функций. Это позволяет вам хранить D
, E
и F
в одном и том же файле, но это не влияет на область действия этих функций, поскольку любая функция, которая может вызывать defineMyFunctions
, может вызывать их. Затем вам также придется позаботиться о передаче дескрипторов функции в качестве аргументов, чтобы убедиться, что они есть там, где они вам нужны.
Копирование D
, E
и F
в B.m
и C.m
в качестве локальных функций. Это ограничивает область их использования только A
, B
и C
, но делает обновление и обслуживание вашего кода кошмаром, потому что у вас есть три копии одного и того же кода в разных местах.
Использование частных функций ! Если у вас есть A
, B
и C
в одном каталоге, вы можете создать подкаталог с именем private
и поместите туда D
, E
и F
, каждый в виде отдельного m-файла. Это ограничивает их область действия, поэтому они могут вызываться только функциями из каталога, расположенного непосредственно выше (т. Е. A
, B
и C
), и хранят их вместе в одном месте (но все же в разных m-файлах):
myDirectory/
A.m
B.m
C.m
private/
D.m
E.m
F.m
Все это выходит за рамки вашего вопроса и, вероятно, более детально, чем вам нужно, но я подумал, что было бы неплохо затронуть более общую проблему организации всех ваших m-файлов. ;)