La première fonction d'un fichier m (c'est-à-dire la fonction principale ) est invoquée lorsque ce fichier m est appelé. Il n'est pas nécessaire que la fonction principale ait le même nom que le fichier m, mais pour plus de clarté, elle devrait l'être . Lorsque la fonction et le nom de fichier diffèrent, le nom de fichier doit être utilisé pour appeler la fonction principale.
Toutes les fonctions suivantes du m-fichier, appelées fonctions locales (ou "sous-fonctions" dans l'ancienne terminologie), ne peuvent être appelées que par la fonction principale et d'autres fonctions locales de ce m-fichier. Les fonctions d'autres m-fichiers ne peuvent pas les appeler. À partir de R2016b, vous pouvez également ajouter des fonctions locales aux scripts , bien que le comportement de portée soit toujours le même (c'est-à-dire qu'ils ne peuvent être appelés qu'à partir du script).
De plus, vous pouvez également déclarer des fonctions dans d' autres fonctions. Ces fonctions sont appelées fonctions imbriquées et ne peuvent être appelées qu'à partir de la fonction dans laquelle elles sont imbriquées. Ils peuvent également avoir accès à des variables dans les fonctions dans lesquelles ils sont imbriqués, ce qui les rend très utiles bien que légèrement difficiles à utiliser.
Plus de matière à réflexion ...
Il existe certains moyens de contourner le comportement de portée de fonction normal décrit ci-dessus, tels que le passage de descripteurs de fonction comme arguments de sortie, comme mentionné dans les réponses de SCFrench et Jonas (qui, à partir de R2013b, est facilité par la localfunctions
fonction). Cependant, je ne suggérerais pas de prendre l'habitude de recourir à de telles astuces, car il existe probablement de bien meilleures options pour organiser vos fonctions et vos fichiers.
Par exemple, disons que vous avez une fonction principale A
dans un m-fichier A.m
, ainsi que des fonctions locales D
, E
et F
. Maintenant que vous avez deux autres fonctions connexes B
et C
dans les fichiers m- B.m
et C.m
, respectivement, que vous voulez aussi être en mesure d'appeler D
, E
et F
. Voici quelques options que vous avez:
Mettez D
, E
et F
chacun dans leurs propres m-fichiers séparés, ce qui permet une autre fonction de les appeler. L'inconvénient est que la portée de ces fonctions est grande et ne se limite pas juste A
, B
et C
, mais le côté positif est que cela est assez simple.
Créez un defineMyFunctions
m-fichier (comme dans l'exemple de Jonas) avec D
, E
et en F
tant que fonctions locales et une fonction principale qui leur renvoie simplement des descripteurs de fonction. Cela vous permet de conserver D
, E
et F
dans le même fichier, mais cela ne fait rien en ce qui concerne la portée de ces fonctions car toute fonction qui peut appeler defineMyFunctions
peut les appeler. Vous devez également vous soucier de passer les poignées de fonction comme arguments pour vous assurer que vous les avez là où vous en avez besoin.
Copiez D
, E
et F
dans B.m
et en C.m
tant que fonctions locales. Cela limite la portée de leur utilisation juste A
, B
et C
, mais la mise à jour et la maintenance marques de votre code un cauchemar parce que vous avez trois exemplaires du même code dans des endroits différents.
Utilisez des fonctions privées ! Si vous avez A
, B
et C
dans le même répertoire, vous pouvez créer un sous - répertoire appelé private
et lieu D
, E
et F
là, chacun comme un fichier séparé m. Cela limite leur portée de sorte qu'ils ne peuvent être appelés que par des fonctions dans le répertoire immédiatement supérieur (c'est-à A
- dire B
, et C
) et les maintient ensemble au même endroit (mais toujours des m-fichiers différents):
myDirectory/
A.m
B.m
C.m
private/
D.m
E.m
F.m
Tout cela dépasse quelque peu la portée de votre question, et est probablement plus détaillé que vous n'en avez besoin, mais j'ai pensé qu'il pourrait être bon d'aborder le souci plus général d'organiser tous vos fichiers m. ;)
^
, @idigas