Lisibilité : Lua VS Axe

[Hayleia]

(Modération : suite de viewtopic.php?f=33&t=14980&p=168124#p168114)

En Axe, dans le code d'un débutant, t'as les variables A à Z (même pas theta). Rien à déclarer,

C'est sûr que ne pas avoir de thêta ni de déclaration simplifie vachement le code, c'est connu. Mais il est encore plus connu que ne pas avoir de nom explicite pour les variables est une calamité à lire, surtout quand les variables se baladent dans tout le code.

Ça, c'est peut-être que mon avis, mais je trouve que trop de déclarations nuisent à la lisibilité. On finit par se demander où commence le code. Sans rire, je mets même souvent mes déclarations à la fin en Axe pour avoir le début du code au début de la source, tout simplement. Vous pouvez demander à nikitouzz, je lui ai passé quelques codes en MP, il confirmera que certes j'ai des déclarations au début, mais j'ai aussi des déclarations à la fin.
Le fait de ne pas avoir de theta rend lisible, oui, car du coup tu sais que toutes les lettres ont le même type et tu n'as pas à te demander si la lettre grecque suit la même règle (voir le "paragraphe" suivant ou mon post précédent).
Les noms de variables explicites sont possibles en Axe mais pour ceux qui codent sur calculatrice, un nom de 13 lettres nuit gravement à la lisibilité vu que l'écran fait 16 caractères de large. À part ça, le T mentionné plus haut est très explicite, il s'agit d'un compteur, T comme Timer, tout va bien. Par contre, comme je code sur PC, j'utilise parfaitement des noms de variable explicites.

tu lis juste la première ligne de son code 0→A et t'as compris que toutes les lettres sont des variables globales "de type nombre".

Cet exemple est moisi, tu peux également faire "A = 0" en Lua (avec le bon sens d'affectation au passage).

Je ne disais pas ici que 0→A est facile à comprendre, ça aurait effectivement été bien moisi. Je disais que cette ligne te permettait de comprendre que les lettres A-Z sont des variables de type nombre.
Et le bon sens d'affectation est bien Source→Dest parce que tu ne mets pas dans le panier la balle, mais la balle dans le panier. De plus, "mets la balle dans le panier" te donne les objets dans l'ordre ou tu les rencontre quand tu exécutes, tu prends bien la balle avant de la mettre dans le panier. De même, le code va d'abord évaluer 0 puis le ranger dans l'emplacement mémoire correspondant à A.

Quand au registre hl, dans le code d'un non débutant il faut effectivement comprendre qu'il se balade, mais dans le code d'un débutant tu peux oublier hl.

Tu qualifies un langage par la façon naïve dont programme un débutant ?

Je n'ai pas dit ça, je dis juste que l'Axe n'est pas "conçu pour être illisible". Parce qu'évidemment, si on prend toujours comme exemple le code illisible d'un pro, tout langage est conçu pour être illisible.

Regarde dans le code que j'ai posté plus haut (qui commence par T++), on aurait pu utiliser hl deux fois en écrivant T++:!If -256:→T:End (ou en une ligne : T++-256??→T (ou en optimisé : {°T}++)), mais on ne l'a utilisé pour des optimisations nulle part.
Et si vous dites que mes icodes dans mes parenthèses sont illisibles... je suis d'accord mais ne dites pas que l'Axe en général est illisible, juste que les codes Axe que vous voyez sur le chat le sont (ce qui est vrai).

Bonjour la scission entre débutants et experts, bien pire que pour les métatables en Lua.

Ça, je ne dis pas. Mais je trouve au contraire qu'il est bien de pouvoir progresser. En plus, l'Axe est souvent mentionné comme une transition entre le Basic et l'ASM (même si je ne sais pas si quelqu'un a vraiment fait du Basic puis de l'Axe puis de l'ASM), il est donc logique d'avoir d'abord du code lisible comme du Basic, puis de moins en moins lisible car on comprend comment tout fonctionne, puis de l'ASM où on décrit absolument tout le fonctionnement du programme.

[mdr1]

Ça, c'est peut-être que mon avis, mais je trouve que trop de déclarations nuisent à la lisibilité. On finit par se demander où commence le code. Sans rire, je mets même souvent mes déclarations à la fin en Axe pour avoir le début du code au début de la source, tout simplement. Vous pouvez demander à nikitouzz, je lui ai passé quelques codes en MP, il confirmera que certes j'ai des déclarations au début, mais j'ai aussi des déclarations à la fin.
Le fait de ne pas avoir de theta rend lisible, oui, car du coup tu sais que toutes les lettres ont le même type et tu n'as pas à te demander si la lettre grecque suit la même règle (voir le "paragraphe" suivant ou mon post précédent).
Les noms de variables explicites sont possibles en Axe mais pour ceux qui codent sur calculatrice, un nom de 13 lettres nuit gravement à la lisibilité vu que l'écran fait 16 caractères de large. À part ça, le T mentionné plus haut est très explicite, il s'agit d'un compteur, T comme Timer, tout va bien. Par contre, comme je code sur PC, j'utilise parfaitement des noms de variable explicites.

Bonjour le mélange entre les variables quand tu appelles des fonctions et que tout est global, bonjour le fait qu'il y a plein de mots qui commencent par un "t", bonjour l'édition de programmes avec 16 caractères par ligne et bonjour la découverte des variables au fur et à mesure de la lecture du code sans savoir à quoi elles servent ni quand elles sont initialisées. Pour info, un code commence toujours au début.

Je ne disais pas ici que 0→A est facile à comprendre, ça aurait effectivement été bien moisi. Je disais que cette ligne te permettait de comprendre que les lettres A-Z sont des variables de type nombre.

Si tu commences à lire un code Axe sans même savoir que A-Z sont des nombres 16 bits, il y a comme un petit souci... Mais l'exemple avec la boucle reste moisi puisque l'on fait quelque chose de similaire en Lua.

Et le bon sens d'affectation est bien Source→Dest parce que tu ne mets pas dans le panier la balle, mais la balle dans le panier. De plus, "mets la balle dans le panier" te donne les objets dans l'ordre ou tu les rencontre quand tu exécutes, tu prends bien la balle avant de la mettre dans le panier. De même, le code va d'abord évaluer 0 puis le ranger dans l'emplacement mémoire correspondant à A.

Tu es en train de jouer sur les mots en montrant ce qui donne la phrase française la plus jolie. D'un point de vue lisibilité, quand tu vois une grosse expression, il est bien mieux de savoir à quoi elle va servir (affectation d'une variable dont on connaît l'utilité) plutôt que de suivre en entier le calcul pour se rendre compte que c'est pour aller dans une variable. C'est comme si tu préférais la syntaxe :

Code basic-nspire : Select all

3*A Disp

plutôt que :

Code basic-nspire : Select all

Disp 3*A

sous prétexte que nativement, le 3*A est exécuté avant.

Je n'ai pas dit ça, je dis juste que l'Axe n'est pas "conçu pour être illisible". Parce qu'évidemment, si on prend toujours comme exemple le code illisible d'un pro, tout langage est conçu pour être illisible.

Non. En l'optimisant, l'Axe devient réellement atroce, et ce n'est pas une question d'expertise. Le registre HL caché fait vraiment mal aux yeux et les instructions peuvent en devenir incompréhensible. Alors qu'un code Lua bien propre même optimisé restera lisible.

Ça, je ne dis pas. Mais je trouve au contraire qu'il est bien de pouvoir progresser. En plus, l'Axe est souvent mentionné comme une transition entre le Basic et l'ASM (même si je ne sais pas si quelqu'un a vraiment fait du Basic puis de l'Axe puis de l'ASM), il est donc logique d'avoir d'abord du code lisible comme du Basic, puis de moins en moins lisible car on comprend comment tout fonctionne, puis de l'ASM où on décrit absolument tout le fonctionnement du programme.

L'assembleur est bien plus lisible que du code Axe que certains nous pondent, avec les instructions à rallonge de 10 lignes où on ne comprend plus ce qui s'additionne avec quoi. Donc l'Axe est attrayant puisqu'au début plus simple mais il devient vite une horreur visuelle, contrairement à l'assembleur où on peut bien voir chaque ligne commentée élémentaire et ce qu'elle fait.

[Adriweb]

Il y a aussi une différence entre un code optimisé (même à fond), et un code obfusqué.
Un code C très optimisé peut être très lisible, contrairement à un code obfusqué (puisque c'est le but...)

Mon impression est qu'avec l'Axe, ces deux aspects pourtant différents se retrouvent mélangés, d'où le fait d'arriver tout de suite à des trucs illisibles quand l'auteur ne cherchait qu'à optimiser.

Je n'y connais rien en Axe, mais bref, vous voyez de quoi je veux parler.

[mdr1]

L'obfuscation ne se limite pas à cela, elle fait également intervenir l'ajout de variables, fonctions, calculs inutiles, et même complexifie des calculs pour aboutir au même résultat, ce qui n'est pas le cas lorsque l'on optimise un code Axe.

[Adriweb]

Ah ben oui, ya plein de "niveaux" d'obfuscation, mais si on se limite a "minifier" le code (sans aller chercher des calculs en plus etc.), c'est déjà pas mal "illisible".

[Hayleia]

Bonjour le mélange entre les variables quand tu appelles des fonctions et que tout est global, bonjour le fait qu'il y a plein de mots qui commencent par un "t", bonjour l'édition de programmes avec 16 caractères par ligne et bonjour la découverte des variables au fur et à mesure de la lecture du code sans savoir à quoi elles servent ni quand elles sont initialisées. Pour info, un code commence toujours au début.

Il y a beaucoup de mots qui commencent par T mais pas tant que ça dans un programme. Et puis les commentaires ne sont pas interdits -.-
Et un code ne commence pas toujours au début, un code C par exemple commence au main, peu importe ce qu'il y a avant.
Et je ne comprends pas la remarque sur "quand elles sont initialisées", on le voit bien quand une variable est initialisée quand même.

Si tu commences à lire un code Axe sans même savoir que A-Z sont des nombres 16 bits, il y a comme un petit souci... Mais l'exemple avec la boucle reste moisi puisque l'on fait quelque chose de similaire en Lua.

Encore une fois, ce n'est pas ce que vous voyez sur TI Planet, mais d'après ce que je vois sur Omnimaga, pas mal de gens écrivent du code Axe sans savoir que A-Z sont des nombres 16 bits, ou sans savoir que Str1 n'est pas une variable.

Tu es en train de jouer sur les mots en montrant ce qui donne la phrase française la plus jolie.

Je ne joue pas sur les mots. Rappel, quand je trolle, je mets un smiley.
Je trouve juste beaucoup plus logique d'écrire dans l'ordre.

D'un point de vue lisibilité, quand tu vois une grosse expression, il est bien mieux de savoir à quoi elle va servir (affectation d'une variable dont on connaît l'utilité) plutôt que de suivre en entier le calcul pour se rendre compte que c'est pour aller dans une variable. C'est comme si tu préférais la syntaxe :

Code basic-nspire : Select all

3*A Disp

plutôt que :

Code basic-nspire : Select all

Disp 3*A

sous prétexte que nativement, le 3*A est exécuté avant.

Alors là, ça dépend. Si le but est de comprendre vite fait le programme, oui, c'est mieux, comme ça on lit juste les membres de gauche et on voit comment on est passé de la position_joueur_dans_map à position_triangle_sur_ecran par exemple. On calcule qui, puis on calcule qui.
Mais si le but est de comprendre comment le programme fonctionne vraiment, les valeurs importent plus que les noms. On calcule quoi, puis on calcule quoi.
Avoir le calcul au début est aussi utile quand tu as des noms de variables longs (ce que vous préconisez) et des longs calculs avec des fautes puisque si la ligne ne tient pas sur l'écran (même sur un écran d'ordinateur), tu vois le calcul en entier au lieu de n'en voir que la moitié.

Par ailleurs, oui, ça m'arrive parfois de préférer A*3 Disp. Pas avec Disp évidemment. Mais voici une ligne (illisible, je vous l'accorde (et oui, c'est une seule ligne)) que j'ai écrite pour le TI Concours, vous pourrez demander à noelthebest (si vous y arrivez), il vous confirmera qu'elle est parue comme ça dans le programme que j'ai soumis et que je ne l'ai pas modifiée entre temps juste pour avoir un argument ici.
Pt-Change(Select(,+(*~1+Xp*(abs()>°MaxC*2-1)//256+{r3+4}^^r+RandPM128()min(max(,~°MaxV)^^r,°MaxV)^^r->r4->{r3+4}^^r)r4+{r3}^^r(??+1)->{r3}^^r)/256, and 0,°Hrt,{r3+2}^^rSelect(,+(*~1+Yp+(31*256)*(abs()>°MaxC*2-1)//256+{r3+6}^^r+RandPM128()min(max(,~°MaxV)^^r,°MaxV)^^r->r4->{r3+6}^^r)r4+{r3+2}^^r->{r3+2}^^r)/256+(*2)*2*2+A)
Inutile de la lire en entier, voyez juste le min(max(,...),...) où j'ai écrit le premier argument du min(max()) avant le min() au lieu de l'écrire dans le max(). Pourquoi ? Parce que dans l'ordre, j'ai besoin de telle valeur, puis j'ai besoin de la restreindre à des limites.

L'assembleur est bien plus lisible que du code Axe que certains nous pondent, avec les instructions à rallonge de 10 lignes où on ne comprend plus ce qui s'additionne avec quoi. Donc l'Axe est attrayant puisqu'au début plus simple mais il devient vite une horreur visuelle, contrairement à l'assembleur où on peut bien voir chaque ligne commentée élémentaire et ce qu'elle fait.

Rien ne t'oblige à faire des instructions de 10 lignes, il n'y a que moi qui fait ça (voir la ligne plus haut). Tu peux même écrire A+B*2 en trois lignes et mettre un commentaire en face de chacune de ces trois lignes si tu veux.

[Adriweb]

Même sans aller chercher des arguments dans la façon d'écrire, il reste tout de même un gros soucis dans l'Axe :
l'obligation d'utiliser des tokens de l'OS (si j'ai bien compris), et du coup, on ne comprend rien si on ne connaît pas les commandes.

Du genre le select, qui ne sélectionne rien du tout...
(il y a surement des exemples plus flagrants, mais je ne les connais pas de tête...)

[Streetwalrus]

Euh, j'ai lu tout ça vite fait mais là vous comparez du vin et des carottes.
Ah, au passage, thêta est une variable en Axe, parmi les noms que j'utilise le plus.

[Adriweb]

Euh, j'ai lu tout ça vite fait mais là vous comparez du vin et des carottes.

Oui ca serait plutôt avantages/inconvénients de ces deux langages
(orienté coding style, à un certain degré...)

[mdr1]

Il y a beaucoup de mots qui commencent par T mais pas tant que ça dans un programme. Et puis les commentaires ne sont pas interdits -.-

Tu veux vraiment mettre un commentaire sur son utilité à chaque fois que tu utilises la variable ?

Et un code ne commence pas toujours au début, un code C par exemple commence au main, peu importe ce qu'il y a avant.

Ah, c'est ce que tu voulais dire... Ben justement, si tu mets tes initialisations à la fin du code, il ne commencera effectivement pas au début et des variables sont utilisées sans avoir ce qu'elles valent et à quoi elles correspondent.[/quote]

Et je ne comprends pas la remarque sur "quand elles sont initialisées", on le voit bien quand une variable est initialisée quand même.

Justement non, pas quand tu mets ça tout à la fin.

Encore une fois, ce n'est pas ce que vous voyez sur TI Planet, mais d'après ce que je vois sur Omnimaga, pas mal de gens écrivent du code Axe sans savoir que A-Z sont des nombres 16 bits, ou sans savoir que Str1 n'est pas une variable.

Et là, comme par enchantement, le débutant écrivit "0->A" et comprit que A était un nombre 16 bits.
Plus sérieusement, je ne comprends pas ce que tu essayes de montrer, là.

Je ne joue pas sur les mots. Rappel, quand je trolle, je mets un smiley.
Je trouve juste beaucoup plus logique d'écrire dans l'ordre.

Tu veux dire dans le désordre ?

Alors là, ça dépend. Si le but est de comprendre vite fait le programme, oui, c'est mieux, comme ça on lit juste les membres de gauche et on voit comment on est passé de la position_joueur_dans_map à position_triangle_sur_ecran par exemple. On calcule qui, puis on calcule qui.
Mais si le but est de comprendre comment le programme fonctionne vraiment, les valeurs importent plus que les noms. On calcule quoi, puis on calcule quoi.
Avoir le calcul au début est aussi utile quand tu as des noms de variables longs (ce que vous préconisez) et des longs calculs avec des fautes puisque si la ligne ne tient pas sur l'écran (même sur un écran d'ordinateur), tu vois le calcul en entier au lieu de n'en voir que la moitié.

Si tu veux savoir comment le programme fonctionne vraiment, rien ne t'empêche de lire le calcul juste après le "=". --'
Je ne préconise en aucun cas des noms à rallonge mais des noms synthétiques, et pas autant qu'une initiale d'une lettre. Si ta ligne ne tient pas sur l'écran d'ordinateur, c'est que tu n'es pas capable de bien présenter ton code. Donc tu vois le calcul en entier.

Par ailleurs, oui, ça m'arrive parfois de préférer A*3 Disp. Pas avec Disp évidemment. Mais voici une ligne (illisible, je vous l'accorde (et oui, c'est une seule ligne)) que j'ai écrite pour le TI Concours, vous pourrez demander à noelthebest (si vous y arrivez), il vous confirmera qu'elle est parue comme ça dans le programme que j'ai soumis et que je ne l'ai pas modifiée entre temps juste pour avoir un argument ici.
Pt-Change(Select(,+(*~1+Xp*(abs()>°MaxC*2-1)//256+{r3+4}^^r+RandPM128()min(max(,~°MaxV)^^r,°MaxV)^^r->r4->{r3+4}^^r)r4+{r3}^^r(??+1)->{r3}^^r)/256, and 0,°Hrt,{r3+2}^^rSelect(,+(*~1+Yp+(31*256)*(abs()>°MaxC*2-1)//256+{r3+6}^^r+RandPM128()min(max(,~°MaxV)^^r,°MaxV)^^r->r4->{r3+6}^^r)r4+{r3+2}^^r->{r3+2}^^r)/256+(*2)*2*2+A)
Inutile de la lire en entier, voyez juste le min(max(,...),...) où j'ai écrit le premier argument du min(max()) avant le min() au lieu de l'écrire dans le max(). Pourquoi ? Parce que dans l'ordre, j'ai besoin de telle valeur, puis j'ai besoin de la restreindre à des limites.

L'assembleur est bien plus lisible que du code Axe que certains nous pondent, avec les instructions à rallonge de 10 lignes où on ne comprend plus ce qui s'additionne avec quoi. Donc l'Axe est attrayant puisqu'au début plus simple mais il devient vite une horreur visuelle, contrairement à l'assembleur où on peut bien voir chaque ligne commentée élémentaire et ce qu'elle fait.

Rien ne t'oblige à faire des instructions de 10 lignes, il n'y a que moi qui fait ça (voir la ligne plus haut). Tu peux même écrire A+B*2 en trois lignes et mettre un commentaire en face de chacune de ces trois lignes si tu veux.

Tu es loin d'être le seul à faire ça et c'est ce qui attend toute personne désireuse d'optimiser son code Axe. Bref, merci pour ton exemple parfaitement illisible, j'avais la flemme d'aller en chercher un moi-même. Je suis curieux d'en voir la version commentée.

@Streetwalker : cette discussion est née de la liste d'Adriweb :

Liste avec juste un exemple par langage :
- Nspire Lua : n'a pas ce qu'il faut par défaut pour créer des GUI
- Axe : le langage est pratiquement fait pour être rendu illisible
- Nspire Basic : pas d'I/O intéressantes
- z80 Basic : pas de fonctions

Mais il est vrai que comparer l'Axe au Lua revient à comparer le Bash au C. ^^