IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Bonnes pratiques de codage sous MATLAB

Vous trouverez dans cet article des conseils pour la programmation sous MATLAB.

Il s'agit surtout de bonnes pratiques permettant d'avoir un code robuste, efficace et lisible.

Ce n'est en aucun cas exhaustif.

Votre avis et vos suggestions sur cet article m'intéressent !
Alors après votre lecture, n'hésitez pas :
8 commentaires Donner une note à l´article (5)

Article lu   fois.

L'auteur

Profil Pro

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Trouver de l'aide sur MATLAB

MATLAB est un logiciel très bien documenté.

Utiliser donc les commandes help, lookfor, doc, le HELPDESK, les démonstrations (demo)...

Si vous ne trouvez pas votre bonheur, voici une liste non exhaustive d'autres outils pouvant vous aider :

En dernier recours, venez poser votre question sur les forums MATLAB de developpez.com : https://www.developpez.net/forums/f148/environnements-developpement/matlab/ (dans ce cas n'oubliez pas de lire les Règles ainsi que le topic Nouveaux membres, débutants : lisez attentivement ceci).

II. Règles de "bonne conduite"

Lorsque l'on programme un outil sous MATLAB, il faut laisser la possibilité à l'utilisateur de continuer à travailler comme il en a l'habitude.

À cette fin il faut éviter toutes les commandes génériques du type : clear all, clc, clf, delete all, close all, bdclose all,...

Pour ne pas risquer :

  • d'effacer des variables dont il a besoin ;
  • de supprimer une figure qu'il souhaite conserver ;
  • de fermer un système Simulink qu'il est en train d'utiliser...

Il ne faut pas déclarer de variables dans le WorkSpace utilisateur, afin de ne pas risquer :

  • d'écraser ses variables ;
  • de polluer son environnement ;
  • que l'utilisateur écrase des variables nécessaires à l'application.

À moins que cela ne fasse partie intégrante de l'outil ou que cela ne soit une demande spécifique des utilisateurs, il faut, tant que faire se peut, éviter les affichages dans la fenêtre MATLAB. Une présentation de résultat doit toujours pouvoir se faire par l'intermédiaire d'une IHM.

Il faut aussi éviter d'utiliser les commandes génériques suivantes : gcf, gcs, ...
À moins d'être absolument sûr de l'objet vers lequel pointent ces fonctions (ex : dans le callback d'une IHM ou d'un modèle on est sûr que gcf (resp. gcs) représente l'IHM (un modèle) dont c'est le callback : préférer d'ailleurs l'utilisation de gcbf ).

III. Conventions de noms : variables

Les noms des variables devraient documenter leur signification ou leur utilité.
Ne pas hésiter, donc, à utiliser des noms longs, en particulier pour les variables importantes.

Les noms de variables peuvent être en mixte minuscules-majuscules, mais devraient commencer par des minuscules (number, numberOfElements). Une alternative peut être d'utiliser des « underscores ».

Éviter d'utiliser les mots réservés de MATLAB, ou les valeurs spécifiques déjà attribuées (if, else, pi, i, j, ...) Un moyen simple d'éviter cela à partir de la version 6.1 de MATLAB est d'utiliser la fonction iskeyword qui fournit les mots-clés de MATLAB.

Les fonctions isvarname et genvarname peuvent aussi être utiles pour construire un nom de variable valide dans MATLAB. Attention cependant, ces fonctions ne tiennent pas compte des recommandations données ici concernant les mots-clés ou les noms de fonction.

Éviter aussi d'utiliser des noms de fonctions MATLAB comme nom de variables (même si a priori MATLAB reconnaît la variable avant la fonction, vous risquez alors de ne plus pouvoir utiliser la fonction).

A cette fin, il peut être utile d'utiliser la commande which de la façon suivante sous MATLAB :

 
Sélectionnez
which variable -all

Si la réponse est vide alors ce nom de variable peut, a priori, être utilisé. « a priori » car si un utilisateur possède des toolboxes que vous n'avez pas vous pourriez très bien avoir utilisé le nom d'une fonction d'une de ces toolboxes sans le savoir.

IV. Conventions de noms : fonctions

Le nom des fonctions doit refléter leur utilité.

Le nom de la fonction et du fichier doivent être le même, ceci pour éviter des confusions.

Le nom des fichiers doit être en minuscules, ceci pour éviter des problèmes potentiels lors d'un changement de système d'exploitation (Windows ne tient pas compte de la casse pour rechercher des noms de fichiers, Unix si et MATLAB aussi).

Avant de nommer une fonction, il est souhaitable de vérifier qu'une telle fonction n'existe pas déjà dans l'environnement MATLAB.

À cette fin, il peut être utile d'utiliser la commande which de la façon suivante sous MATLAB :

 
Sélectionnez
which nomfonctionsansextension -all

Si la réponse est vide alors ce nom peut, a priori, être utilisé. « a priori » car si un utilisateur possède des Toolboxes que vous n'avez pas vous pourriez très bien avoir utilisé le nom d'une fonction d'une de ces toolboxes sans le savoir.
La longueur du nom du fichier doit être de moins de N caractères avec N la valeur retournée par la fonction namelengthmax.

V. Lisibilité et organisation

Utiliser des structures plutôt que des variables globales et les utiliser comme variables d'entrées et sorties des fonctions. Cela permet d'avoir des fonctions modulaires, et cela aide à organiser les variables.

Pour enregistrer des variables penser à utiliser les fonctions setappdata / getappdata plutôt que des variables globales.

Et surtout, évidemment, ne pas déclarer de variables dans le WorkSpace MATLAB.

Si des variables ne sont utilisées que dans le cadre d'une IHM, plusieurs solutions existent qui sont décrites dans le tutoriel : Développement efficace des interfaces graphiques (GUI)

Éviter les fonctions eval, feval, exist : cela rend le code très confus et peut poser des problèmes si vous souhaitez compiler votre code.

Éviter les MEX-files quand cela est possible. La plupart du temps une simple vectorisation est la solution appropriée et permet de tout garder dans le même langage multiplatesforme, ouvert et facilement modifiable.

Les fonctions doivent être courtes. Elles peuvent être réutilisées par d'autres fonctions. Cela les rend plus facile à lire et à organiser. Si une fonction est utilisée uniquement par une autre, elle peut être incluse dans le même fichier (sous-fonction ou fonction imbriquée).

Essayer, si possible, de retourner un code d'erreur à chaque fonction.

Séparer toute partie de code générique dans une autre petite fonction.

Faire des lignes courtes en s'aidant des caractères de continuation (...).

Utiliser l'indentation standard de l'éditeur MATLAB (utiliser des tabulations).

Dans l'éditeur MATLAB cela est facilité soit :

  • par l'utilisation du menu Text > Smart Indent ;
  • par l'utilisation du clavier et des combinaisons Ctrl+A pour sélectionner le code et Ctrl+I pour l'indenter.

Segmenter les problèmes.

VI. Interfaces

Les interfaces doivent être créées en fonction de la taille de l'écran.

La ligne de commande suivante :

 
Sélectionnez
s = get(0,'screensize')

permet d'accéder à cette taille.

Attention cependant aux unités : celle de l'écran et de la figure doivent être les mêmes.

Ou utiliser l'unité « normalized » : l'écran est alors de taille 1*1.

De même les éléments de la fenêtre doivent être placés en fonction de la taille de la fenêtre.

Utiliser les paramètres :

  • HandleVisibility = 'off' => le handle de l'IHM n'est visible que dans ses callback
  • IntegerHandle = 'off' => le handle de l'IHM n'est pas un entier

Ces deux paramètres évitent a l'utilisateur de supprimer les IHM de façon intempestive.

Laisser autant que possible à l'utilisateur la possibilité de modifier la taille de l'IHM (propriété Resize = 'on'). Cela peut être utile en particulier pour les boîtes de dialogue standard MATLAB (inputdlg, msgbox...) dont le titre est parfois trop long pour être visible avec la taille par défaut.

Ne pas mettre directement les actions dans les callbacks mais préférer un appel à une fonction unique derrière chaque callback d'une même IHM (comme cela est fait automatiquement par le GUIDE à partir de la version 6.1 de MATLAB).

Cela permet :

  • des modifications plus aisées (pas besoin d'ouvrir à nouveau le GUIDE) ;
  • des messages d'erreurs éventuellement plus clairs et plus ciblés

Note : Agir de la même façon pour les fonctions appelées dans les modèles Simulink : les *fcn des modèles et sous-systèmes, et les fonctions appelées dans les masques.

Avoir une unité de langue, de couleur, et éviter les couleurs "agressives".

Tout élément modifiable a en général un fond blanc (objets de style popup, listbox, edit) : on ne les grisera que si l'utilisateur ne peut pas les modifier.

Désactiver tout élément tant qu'il ne peut pas être utilisé (avec la propriété Enable = 'inactive', il sera alors grisé automatiquement).

Utiliser la police obtenue par la commande suivante :

 
Sélectionnez
fontName = get(0,'FixedWidthFontName')

Cette police est celle, pour la plate-forme en cours, telle que chaque lettre fait la même largeur.

Cela peut-être très utile par exemple pour créer des structures arborescentes, ou des tableaux dans des objets de type liste.

VII. Optimisation de la rapidité d'exécution

Utiliser des structures de tableaux et non des tableaux de structures, à moins que cela ne soit important pour votre code. Les tableaux de structures ralentissent l'exécution.

Éviter la fonction deal

Essayer de déclarer les variables avec leur taille en utilisant les fonctions du style zeros ou ones . Voir à ce sujet : Qu'est-ce que la préallocation de mémoire ?

Utiliser la fonction profile ou le profiler de MATLAB afin de cerner les parties dans lesquelles l'exécution prend le plus de temps.

VIII. Commentaires

On ne dira jamais assez l'importance des commentaires. Ceci est vrai quelque soit le langage informatique.

Avec MATLAB le commentaire se fait grâce au signe %. Il peut se mettre en début de ligne ou après une ligne de code. Tout ce qui se trouve derrière le signe % sera ignoré lors de l'exécution du code.

Quelques spécificités MATLAB :

  • La 1ère ligne de commentaire d'un fichier est appelée la "H1 Line" : c'est celle qui sera affichée lors d'une recherche avec la commande lookfor
  • Les 1ères lignes de commentaires d'un fichier sont celles qui seront affichées lors de l'appel avec la fonction help : elles sont donc très importantes car elles doivent renseigner l'utilisateur sur l'objectif et l'utilisation de la fonction

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Copyright © 2009-2013 Caro-Line. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.