Discussion :

[ol9245]

Bonjour,

je me demande si il existe dans Matlab des espaces de travail (un peu comme en C) à l'intérieur desquels on peut définir des variables qui ne sont visibles que de l'intérieur de cet espace.

un peu dans cet esprit là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
a=1 ;
disp(a) % -> 1
{ % ouvrir un espace
a = 2 ;
disp(a) % -> 2
b = 3 ;
disp(exist('b')) % -> 1
} % fermer l'espace
disp(a) % -> 1 : c'est celui de l'espace contenant qui redevient visible
disp(exist('b')) % -> 0 : b n'est plus visible

comme je crois que la réponse est non, je voudrais savoir quelles stratégies/méthodes/astuces vous développez pour éviter de réutiliser/écraser des variables déja existantes dans les codes un peu longs.

[mr_langelot]

Bonjour,

1) tu as les fonctions,
2) tu as la fonction "clear" qui te permet de supprimer la variable, pour utiliser la variable plus loin en évitant ainsi d'éventuelles interférences.

Pour le scope entre {} du C, je ne suis pas persuadé que ça existe.

[Caro-Line]

En utilisant les fonctions, chaque fonction ayant son propre espace de travail (Quelle est la durée de vie des variables ?)

Pour ton exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
function toto()
a=1 ;
disp(a) % -> 1
tata; % appel
 
disp(a) % -> 1 : c'est celui de l'espace contenant qui redevient visible
disp(exist('b')) % -> 0 : b n'est plus visible
 
function tata()
a = 2 ;
disp(a) % -> 2
b = 3 ;
disp(exist('b')) % -> 1

[ol9245]

Oui, les fonctions, je sais...
ceci dit, Matlab n'incite pas vraiment à multiplier les fonctions
Ne serait-ce que parce que on ne peut pas écrire de fonction à la fin d'un script (limitation totalement inutile à mon sens. Mais bon, c'est pas moi le patron ).
Si on se met à faire plein de fonctions de partout comme en C, ca devient vite casse-pied, avec des diarrhées de fichiers .m dont on n'arrive plus à trier l'important du bas-niveau.

donc pour mes projets, qui sont à courte durée de vie (j'utilise Matlab pour prototyper des modèles numériques qui sont ensuite éventuellement portés en C++), j'évite "comme tout le monde" d'écrire beaucoup de fonctions. Du coup mes noms de variables se marchent sur les pieds.

[Caro-Line]

ceci dit, Matlab n'incite pas vraiment à multiplier les fonctions
...
j'évite "comme tout le monde" d'écrire beaucoup de fonctions.

Je n'utilise jamais de scripts, ou alors pour des tests...
Je ne fais que des fonctions, et je m'y retrouve très bien.

Dans ma tête les scripts ne peuvent servir qu'aux gens qui utilisent Simulink qui peut avoir besoin de variables dans le workspace....

Et je ne vois vraiment pas d'autre méthode pour garder des environnements de travail propres.

Mais bon je suppose que ça dépend de ce que chacun fait

[ol9245]

Mon travail avec Matlab est typiquement une approche de script.
J'écris d'abord mes modèles numériques avec papier-crayon etc.

Puis je les code dans des script matlab pour vérifier les propriétés numériques, générer les figures pour illustrer le modèle etc. Ce genre de script fait environ une centaine de ligne. sa durée de vie est d'une semaine à un mois.

Dans une phase suivante, je peux vouloir faire des simulations plus intensives. Ca va générer quelques centaines de ligne de code. Donc là, effectivement j'ai le choix d'investir du temps pour structurer le code etc. etc. En général je le fais pas parceque ça représente du temps de développement que je n'ai pas nécessairement sous la main. Inutile de faire un code propre si sa durée de vie est inférieure à 6 mois !

Puis, si le modèle tient ses promesses, que plusieurs personnes se mettent à bosser dessus, il y a des décisions collégiales qui sont prises pour intégrer ces fonctionnalités dans l'environnement de modélisation maison. Là, tout est ré-écrit en C++ et c'est plus moi qui m'en occupe.

C'est donc vraiment du prototypage que je m'occupe.

En prototypage, on n'a pas de plan de développement très précis. je navigue à vue. Il faut inspecter à chaque étape ce que crache le modèle, et modifier les options numériques en cours de route. Pour ça, je suis bien content d'avoir mes variables de travail dans le workspace global. Même si j'utilise pas Simulink.

Par contre, si j'avais à disposition un niveau d'organisation intermédiaire, j'en ferais de l'usage.

[Jerome Briot]

Ne serait-ce que parce que on ne peut pas écrire de fonction à la fin d'un script (limitation totalement inutile à mon sens. Mais bon, c'est pas moi le patron ).

A chaque exécution, un script est exécuté ligne par ligne, peu importe le nombre d'exécution.

Alors qu'une fonction est pre-compilée à sa première exécution. Dans toutes les exécutions suivantes, c'est la version pré-compilée qui est exécutée. D'où une exécution généralement (un peu) plus rapide.

Ces deux façons de procéder rendent la déclaration de fonctions à l'intérieur d'un script assez hasardeuse...

Pour le reste, je ne connais pas non plus de méthode permettant de répondre à ton problème...

D'un autre coté, j'ai appris à ne pas appeler mes variables a ou b... pour éviter de les écraser par inadvertance

[ol9245]

c'est intéressant ça. Je n'avais jamais fait attention au fait que les scripts ne sont pas précompilés. C'est pourtant pas le temps que ça prendrait qui serait gênant...

pour les noms de variables, je suis un peu comme toi (des noms de variable qui ont du sens) mais les petits noms ont du bon quand même (et même en C). Sans remonter à la nuit des temps , avant mon passage récent à Matlab j'étais en C++, avec toute sa culture de hiérarchie de fonctions/méthodes bas-niveau x haut-niveau etc. C'est intélectuellement séduisant, mais en pratique, moins. Avant de commencer à construire, on avait surtout l'impression de creuser .

En passant à Matlab, je me suis vautré avec délectation dans le code improbable (et qui marche). 1h de développement Matlab, c'est 3 jours de travail en C++. Je n'ai pas spécialement envie de me remettre à programmer proprement . D'ou ma recherche de solutions intermédiaires...

[mr_langelot]

Bonjour,

je ne suis pas sûr que ce que tu appelles coder "proprement" prenne plus de temps...
J'ai fait des outils d'analyses pour des modèles simulink. Je les alimentais avec des données d'entrées et je faisais des graphs avec les sorties.

Structurer son code, faire une fonction pour chaque tâche m'a toujours permis de gagner du temps parce que :
- j'arrivais à isoler les problèmes facilement quand il y en avait.
- dans ma tête, c'est clair et dans mon code, ça l'est aussi.
- J'ai toujours pu faire évoluer mon code facilement.

Par contre, c'est vrai qu'il peut y avoir un investissement de départ

on s'éloigne aussi du sujet

[ol9245]

Bonjour,

je ne suis pas sûr que ce que tu appelles coder "proprement" prenne plus de temps...
J'ai fait des outils d'analyses pour des modèles simulink. Je les alimentais avec des données d'entrées et je faisais des graphs avec les sorties.

Structurer son code, faire une fonction pour chaque tâche m'a toujours permis de gagner du temps parce que :
- j'arrivais à isoler les problèmes facilement quand il y en avait.
- dans ma tête, c'est clair et dans mon code, ça l'est aussi.
- J'ai toujours pu faire évoluer mon code facilement.

Par contre, c'est vrai qu'il peut y avoir un investissement de départ

on s'éloigne aussi du sujet

Oui, on s'éloigne mais c'est pas gênant vu que je crois bien que la réponse à la question intiale est bouclée.

Disons que quand il suffit de 200 lignes de code matlab pour faire un prototype de modèle numérique, la question du code propre ne se pose pas. En tout cas mons que si on travaillait dans un langage qui nécessitait 2000 ou 10000 lignes de code.

L'autre chose à prendre en considération est l'expérience de chacun. Ce que j'estime propre aujourd'hui est différent de ce que j'estimais propre il y a 20 ans.

La propreté n'est pas non plus une fin en soi. Il faut aussi considérer la productivité, et la durée de vie. C'est u tout. Il n'y a pas un impératif qui domine l'autre, mais de savants équilibres issus de l'expérience et relatifs au contexte.

Et puis tout cela reste très subjectif. La propreté d'un code c'est un peu comme la santé : si personne ne s'en plaint, c'est que tout va bien . Après, tu trouvera toujours les fondus de footing qui prétendent faire ça pour leur santé. Sont ils en meilleure santé que les autres ? en fait, nul ne le sait.

[mr_langelot]

Je suis d'accord avec tout ce que tu dis.

Les gens très "puristes" sont même plus malfaisant que les gens qui codent "à la volée".

Il faut bien sûr adapter son effort au problème et je suis le premier à faire des gros .m avec la moitié du code que je commente/décommente selon les besoins.

D'un autre côté, si tu as posté ce sujet, c'est que ta manière de coder atteint ses limites, non ?

bon, j'espère que la discussion ne s'est pas transformé en troll... de mon fait, en plus...

[ol9245]

Je suis d'accord avec tout ce que tu dis.

Les gens très "puristes" sont même plus malfaisant que les gens qui codent "à la volée".

Il faut bien sûr adapter son effort au problème et je suis le premier à faire des gros .m avec la moitié du code que je commente/décommente selon les besoins.

D'un autre côté, si tu as posté ce sujet, c'est que ta manière de coder atteint ses limites, non ?

bon, j'espère que la discussion ne s'est pas transformé en troll... de mon fait, en plus...

non non, comme j'ai dit la question technique est épuisée donc on peut bavarder pas de souci.

Je suis content qu'on se soit compris . C'est pas toujours évident d'expliquer pourquoi on fait pas tout dans les règles et qu'on a des bonnes raisons pour ça.

Et pour ce qui est de ma manière de coder, pas de souci. J'en ai encore sous le pied . Comme tu le dis à juste titre, je mesure mon effort. Donc c'est pas parceque mon .m est plus gros que ses petits frères que je vais m'arrêter de faire mon métier pendant une semaine pour mettre mon code au propre.

Tu parles de gros morceaux de .m qui sont commentés ou pas. Là tu vois, j'ai franchis une petite étape à l'occasion de mon dernier code : je laisse tout ! et je fais comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
mon_option_du_jour = 'a larrache' ; % autre options : dur, mou.
 
if strcmpi(mon_option_du_jour, 'a larrache')
    % bla
    % bla
    % bla
elseif  strcmpi(mon_option_du_jour, 'dur')
    % bla
    % bla
    % bla
elseif  strcmpi(mon_option_du_jour, 'mou')
    % bla
    % bla
    % bla
else
   error ('option inconnue')
end

l'avantage :
* le code des options précédentes reste lisibles.
* pas de bug en le réactivant (et en oubliant de décommenter un morceau)
* c'est plus ou moins prêt au cas ou le code doive évoluer vers des fonctions séparées

[Caro-Line]

Sinon le SWITCH c'est bien quand on a des IF/ELSEIF en pagaille

[ol9245]

Sinon le SWITCH c'est bien quand on a des IF/ELSEIF en pagaille

oui, le switch c'est bien mais à ma connaissance ça marche pas avec les chaines de caractère, d'ou mon choix qui, à l'origine, est surtout fait pour augmenter (d'un tout petit pouillème) la lisibilité de mon code donc -> utilisation de if/elseif + chaine de caractère pour qualifier les différentes options.

[Jerome Briot]

oui, le switch c'est bien mais à ma connaissance ça marche pas avec les chaines de caractère,

Bien sur que si :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
mon_option_du_jour = 'a larrache' ; % autre options : dur, mou.
 
switch lower(mon_option_du_jour)
   case 'a larrache'
    % bla
    % bla
    % bla
   case 'dur'
    % bla
    % bla
    % bla
   case 'mou'
    % bla
    % bla
    % bla
   otherwise
   error ('option inconnue')
end

[ol9245]

Bien sur que si :

trop for Dut !
(je sais pas d'ou je tenais le contraire )