Lisibilité : Lua VS Axe

[Adriweb]

(sauf que je n'ai nullement lancé un comparatif entre ces langages, moi )

[Hayleia]

Par contre, cette discussion n'est pas vraiment "Lua vs Axe" mais plutôt "Lisibilité : Lua vs Axe", donc si quelqu'un pouvait éditer le titre, ça serait bien. Parce que ça ne me viendrait pas du tout à l'idée de comparer le Lua et l'Axe en général.

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

Non mais juste si ton Timer s'appelle T et que ta variable Temporaire ne peut plus s'appeler T, tu mets un (un seul) commentaire en début de programme disant que U c'est ta variable Temporaire.

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.

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.

J'ai jamais dit que je mettais les initialisations à la fin, mais les déclarations. Donc tu vois très bien à quoi les variables sont initialisées juste avant le Main Loop (qui d'ailleurs est précédé d'un "Lbl Main" dans mes programmes, pour pouvoir utiliser la fonctionnalité JumpToLabel de zStart). Sauf le °TitleScreenBG (qui n'est pas une variable d'ailleurs) mais avec un nom pareil, pas vraiment besoin de dire à quoi il correspond.

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à.

Normal, d'après le paragraphe précédent, tu inventes des phrases que je n'ai pas dites et tu oublies celles que j'ai dites.
Ce que je dis ici, c'est qu'on a pas besoin de déclarer (avec la syntaxe C) "uint16_t A". En lisant le "A=0", tout le monde comprend que A est un nombre. On ne voit pas combien de bits il fait mais pour comprendre un programme "normal" d'Axe, c'est largement suffisant.

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.

Effectivement, en fait, à part certaines lignes comme celle que j'ai donnée en exemple, toutes mes lignes tiennent sur mon écran. Ce que je voulais dire c'est qu'elles ne rentrent pas dans la fenêtre puisque je ne maximise pas mes fenêtres.
Du coup, ça m'oblige à scroller pour lire le calcul après le "=". Ça n'est pas un empêchement, mais quand même un embêtement.

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.

Complètement faux. Si tu savais de quoi tu parles, tu aurais en tête du Runercode, l'Axe le plus optimisé au monde, et en Runercode, très peu de lignes sont longues. Dans Graylib j'en compte deux, dont une qui tient dans ma fenêtre, et une qui a deux commandes Asm() dedans et qui ne serait donc pas plus lisible en 20 lignes. Toutes les autres lignes (sans compter les commentaires et les déclarations) tiennent en moins de 23 tokens.
Et il n'y a pas de version commentée. À part le Pt-Change, cette ligne (avec la précédente tout de même) se lit très bien de gauche à droite puisque tous les calculs sont effectués dans l'ordre. C'est bien toi qui trouve la RPN plus claire que MathPrint, non ? Alors tu peux comprendre que je puisse préférer les calculs dans l'ordre, non ?

[mdr1]

Non mais juste si ton Timer s'appelle T et que ta variable Temporaire ne peut plus s'appeler T, tu mets un (un seul) commentaire en début de programme disant que U c'est ta variable Temporaire.

Si tu n'utilises que deux variables, ça va, mais quand tu commences à faire un programmer avec 50 variables, bonjour pour se souvenir de chaque initiale.

J'ai jamais dit que je mettais les initialisations à la fin, mais les déclarations.
Donc tu vois très bien à quoi les variables sont initialisées juste avant le Main Loop (qui d'ailleurs est précédé d'un "Lbl Main" dans mes programmes, pour pouvoir utiliser la fonctionnalité JumpToLabel de zStart). Sauf le °TitleScreenBG (qui n'est pas une variable d'ailleurs) mais avec un nom pareil, pas vraiment besoin de dire à quoi il correspond.

Des déclarations ? Ça n'existe pas en Axe et tu as même dit que tant mieux, car ça nuit à la lisibilité du code.

Normal, d'après le paragraphe précédent, tu inventes des phrases que je n'ai pas dites et tu oublies celles que j'ai dites.
Ce que je dis ici, c'est qu'on a pas besoin de déclarer (avec la syntaxe C) "uint16_t A". En lisant le "A=0", tout le monde comprend que A est un nombre. On ne voit pas combien de bits il fait mais pour comprendre un programme "normal" d'Axe, c'est largement suffisant.

C'est bien cela, pas de déclaration. Bon, bref, te cognant au mur de la difficulté, tu parles maintenant de programmes "normaux" d'Axe. Et que penses-tu des programmes "normaux" en Lua ?

Effectivement, en fait, à part certaines lignes comme celle que j'ai donnée en exemple, toutes mes lignes tiennent sur mon écran. Ce que je voulais dire c'est qu'elles ne rentrent pas dans la fenêtre puisque je ne maximise pas mes fenêtres.
Du coup, ça m'oblige à scroller pour lire le calcul après le "=". Ça n'est pas un empêchement, mais quand même un embêtement.

C'est bien ce que je dis, le code est mal présenté. Même quand on fait une ligne très longue, on doit être capable de la mettre sur plusieurs niveaux, correctement indentés et commentés.

Complètement faux. Si tu savais de quoi tu parles, tu aurais en tête du Runercode, l'Axe le plus optimisé au monde, et en Runercode, très peu de lignes sont longues. Dans Graylib j'en compte deux, dont une qui tient dans ma fenêtre, et une qui a deux commandes Asm() dedans et qui ne serait donc pas plus lisible en 20 lignes. Toutes les autres lignes (sans compter les commentaires et les déclarations) tiennent en moins de 23 tokens.

Les lignes en Axe n'ont pas besoin d'être longues pour être incompréhensibles. Des flèches que l'on met deux fois de suite, des symboles degré et exposant r qui se baladent partout, bref, rien de sémantique.

Et il n'y a pas de version commentée.

C'est bien le problème, c'est que la ligne s'écroule tellement sur elle-même à cause de HL qu'un commentaire étape par étape s'avère difficile car il n'y a pas d'étape. Bonjour la maintenance.

À part le Pt-Change, cette ligne (avec la précédente tout de même) se lit très bien de gauche à droite puisque tous les calculs sont effectués dans l'ordre. C'est bien toi qui trouve la RPN plus claire que MathPrint, non ? Alors tu peux comprendre que je puisse préférer les calculs dans l'ordre, non ?

Non, tu confonds tout. Tu n'as jamais utilisé mon programme SaisieRPN visiblement. Il permet de saisir les calculs en RPN parce que c'est plus rapide, c'est tout. Mais ils sont affichés normalement.

[Hayleia]

Si tu n'utilises que deux variables, ça va, mais quand tu commences à faire un programmer avec 50 variables, bonjour pour se souvenir de chaque initiale.
.

Sauf que

• tu ne peux pas avoir 50 initiales,
• de toute façon, personne n'utilise 50 variables, en tout cas pas en Axe,
• si tu utilises vraiment 50 variables, rien ne t'empêche d'en déclarer, et puisque d'après le premier point, tu ne peux pas avoir 50 initiales, autant déclarer 50 variables avec un nom potable.

Des déclarations ? Ça n'existe pas en Axe et tu as même dit que tant mieux, car ça nuit à la lisibilité du code.

Si ça existe, tu peux très bien mettre L5+02→°MaVariable n'importe où dans ton code, y compris à la fin pour ne pas nuire à la lisibilité, et tu obtiens une variable qui s'appelle MaVariable avec laquelle tu peux faire MaVariable++ et tout ce que tu veux.

C'est bien cela, pas de déclaration. Bon, bref, te cognant au mur de la difficulté, tu parles maintenant de programmes "normaux" d'Axe. Et que penses-tu des programmes "normaux" en Lua ?

J'ai toujours parlé des programmes "normaux" ou "de débutants", c'est juste toi qui a encore inventé quelque chose dans mes paroles en disant que je parlais de programmes optimisés.
Les programmes "normaux" en Lua utilisent tous le "platform.window:invalidate()" dont j'ai parlé plus tôt et qui n'est pas clair selon moi. Déjà, à quoi sert "platform" ? À dire que la fenêtre dont on va parler n'est pas une fenêtre de mon Android ? Inutile. Ça ne fait que rallonger la ligne et embrouiller le lecteur en lui faisant croire qu'il y a des choses à lire. La partie "window" est la seule sur laquelle je n'ai rien à dire. Quant à "invalidate", ça a beau être utilisé dans beaucoup de librairies graphiques, ça reste obscur.

On n'a qu'à prendre un exemple pour clore le débat. Faisons un programme qui déplace un carré à l'écran en utilisant les touches de directions, écrit de la manière dont un débutant l'écrirait. Voilà ce que ça donne en Axe :

Code: Select all

.AA
0->X
0->Y
While 1
  ClrDraw
  If getKey(1)
    Y++
  End
  If getKey(4)
    Y--
  End
  If getKey(2)
    X--
  End
  If getKey(3)
    X++
  End
  Rect(X,Y,8,8)
  DispGraph
End If getKey(15)


Faut l'inventer quand même la ligne qui ne serait pas claire dans ce code.

C'est bien ce que je dis, le code est mal présenté. Même quand on fait une ligne très longue, on doit être capable de la mettre sur plusieurs niveaux, correctement indentés et commentés.

Ah mais ça on peut le faire en Axe aussi. C'est juste qu'on en a jamais besoin puisque notre calcul est au début, tient sur la ligne (encore une fois, ne prenez pas mes programmes pour exemple), et le →Variable est à la fin, au pire sur la ligne d'en dessous, comme ça :

Code: Select all

LeDébutDuCalcul LaFinDuCalcul
→CeciEstMaVariable


Il n'y a que vous pour faire ça :

Code: Select all

CeciEstMaVariable = LeDébutDuCalcul ##notez les espaces inutiles de part et d'autre du "="
                    LaFinDuCalcul ##je dois aller à la ligne puisque j'ai gâché de la place


Les lignes en Axe n'ont pas besoin d'être longues pour être incompréhensibles. Des flèches que l'on met deux fois de suite,

Tu vas pas me dire que 0→A→B est illisible quand même -.-
Et les débutants ne l'utilisent pas, il chargent 0 deux fois, comme dans mon exemple ci-dessus.

des symboles degré

Que les débutants n'utilisent pas non plus.

et exposant r qui se baladent partout

D'abord, petite précision pour ceux qui ne connaissent pas l'Axe (ceci ne vise personne) : le ^^r, c'est ce que sort TokenIDE. En vrai, ça ressemble à ^r. C'est tout de suite moins long et moins moche.
Deuxièmement, chez les très débutants, il n'y a pas non plus ce ^r, mais on va éviter de parler d'eux quand même.
Et chez les pas trop débutants, il y a ce ^r, mais soit toujours après une "}", soit toujours après une commande de dessin. Même si tu ne comprends pas son but exact, tu comprends toujours que la commande de dessin dessine, et ce n'est pas le ^r qui va t'empêcher de comprendre les {}, qui certes ne parlent pas d'elles mêmes mais qui ne sont pas moins claires que l'étoile en C (surtout avec le coding style ridicule en C que les gens utilisent en écrivant int *a au lieu de int* a).

Et il n'y a pas de version commentée.

C'est bien le problème, c'est que la ligne s'écroule tellement sur elle-même à cause de HL qu'un commentaire étape par étape s'avère difficile car il n'y a pas d'étape. Bonjour la maintenance.

Sauf qu'encore une fois, si on cherche à étudier la lisibilité de l'Axe, il ne faut pas lire mes programmes. Mais même en parlant de ce programme, un commentaire par étape est inutile puisque si, il y a des étapes, et elles s'effectuent bêtement de gauche à droite. Inutile de commenter.
Quand à la maintenance, pourquoi faire ? On n'a pas de problèmes d'API 2.0 ou je ne sais quoi, nous.

Non, tu confonds tout. Tu n'as jamais utilisé mon programme SaisieRPN visiblement. Il permet de saisir les calculs en RPN parce que c'est plus rapide, c'est tout. Mais ils sont affichés normalement.

Je ne confonds rien du tout. Tu crois que mon programme quand il tourne, il affiche et des trucs illisibles à l'écran ? Non.
Donc toi quand tu écris ton calcul, tu l'écris en RPN illisible selon certains mais plus intuitif selon toi tout comme moi j'écris mes calculs dans l'ordre illisible selon certains mais plus intuitif selon moi, et ce sans que cela ne change rien au résultat final chez toi comme chez moi.

[m@thieu41]

Vous vous rendez compte que cette discussion ne sert à rien ?

D'un côté il y a un langage fait pour être programmé sur petit écran, directement on-calc, compilé et non orienté objet, et limité par les capacités de mémoire de la calto.
De l'autre, un langage qu'on utilise sur grand écran, avec coloration syntaxique, interprété, orienté objet, et peu limité niveau mémoire.

Donc c'est sur que là où on peut écrire de manière aérée et agréable à lire en lua... on est plus restreint en Axe.
Donc utiliser par exemple une variable de nom degatsEnnemis en Axe revient à prendre quasiment une ligne ! Alors qu'en lua ça ne représente rien. Normal qu'ils préfèrent les noms courts en Axe...
C'est comme de dire que les variables en basic z80 sont pénibles car on ne sait pas à quoi correspond "A" ou "E". Certes, mais à force de n'utiliser que les mêmes variables d'une lettre, on finit pas leur attribuer un "rôle" : A l'absice, B l'ordonnée, C déplacement horizontal, D déplacement vertical, W/I/théta : variables pour boucler, V la vie, T le nombre de tours, J le numéro du joueur, K le codeTouche, etc.

Après certes un code optimisé en Axe ça donne quelque chose d'ilisible... mais en même temps c'est un langage compilé, proche du fonctionnement de la calto! Alors que le lua est un langage interprété.

De la même façon, je peux dire que le lua est pour moi difficilement lisible dans certains cas, ou du moins déconcertant, parce que les variables sont globales au lieu d'être locale par défaut... C'est assez peu logique pour un langage comme ça, convenez en...

Concernant le platform.window:invalidate() : si ça ne te plait pas, tu peux très bien mettre screen = platform.window, du coup après tu peux faire : screen:invalidate();

Ton argument des espaces entre le "=" est irrecevable : quand on a un grand écran, on ne cherche pas à gagner de la place sur ça (même si ça reste possible).
C'est comme si tu disais que la langue française est illisible parce qu'il y a des espaces entre les mots! Tuemecomprendsvraimentmieuxsijeteparlecommeçasansaccents? Non, d'où l'utilité de mettre des espaces : aérer, et rendre plus lisible.


Vous voyez donc que cette discussion est inutile : autant comparer le ti basic z80 et le C++ --"

[Adriweb]

On n'a qu'à prendre un exemple pour clore le débat. Faisons un programme qui déplace un carré à l'écran en utilisant les touches de directions, écrit de la manière dont un débutant l'écrirait. Voilà ce que ça donne en Axe :

Code: Select all

.AA
0->X
0->Y
While 1
  ClrDraw
  If getKey(1)
    Y++
  End
  If getKey(4)
    Y--
  End
  If getKey(2)
    X--
  End
  If getKey(3)
    X++
  End
  Rect(X,Y,8,8)
  DispGraph
End If getKey(15)


Faut l'inventer quand même la ligne qui ne serait pas claire dans ce code.

Un problème évident avec la lecture de ce code :
on ne sait pas à quoi correspondent les touches (codes du getKey) !
Autre chose, mais un peu moins important : qu'est-ce que c'est que ce ".AA" en haut tout seul ?
Donc oui, c'est clair avec un peu de réflexion, mais ça peut l'être encore plus et sans trop réflexion (et c'est donc plus verbeux, oui, mais... et alors ?) :

Code: Select all

x,y = 0,0

function on.arrowKey(dir)
    if dir == "left" then
        x = x-1
    elseif dir == "right" then
        x = x+1
    elseif dir == "up" then
        y = y-1
    else
        y = y+1     
    end
    platform.window:invalidate()
end

function on.paint(gc)
    gc:drawRect(x, y, 8, 8)
end

Alors, oui, le invalidate() peut effrayer si on ne sait pas que c'est le terme standard (quoiqu'un anglophone comprendra parfaitement de toute façon), mais le reste me semble tout de même très clair

Quand à la maintenance, pourquoi faire ? On n'a pas de problèmes d'API 2.0 ou je ne sais quoi, nous.

Mon avis là-dessus est que de la maintenance, il va forcément y en avoir si le projet est suffisamment important où que le code est partagé entre plusieurs personnes etc.
Donc sans commentaires, ça devient insane pour une personne tierce de comprendre du code fortement optimisé...
On ne parle même pas de problèmes d'API (au passage, il y en a eu vraiment peu, des problèmes, puisqu'on peut en gros revenir en apilevel "1.0" même en 3.9 (c'est ce qui se passe automatiquement sur des vieux scripts). Les fonctions non documentées, par contre, sont à utilisées à ses risques et périls.

surtout avec le coding style ridicule en C que les gens utilisent en écrivant int *a au lieu de int* a)

... ou comment déclarer une autre guerre...
(même si je n'aime pas non plus int *a, et préfère donc int* a.)
2 façons d'interpréter les manières d'écrire : l'un dit que "*a" est un int, et l'autre dit que "a" est un pointeur vers un int. Deux façons de penser...
Un avantage de déclarer ses variables avec "int *a" est qu'on peut facilement chaîner les déclarations : int *a, *b, *c, alors que int* a, b, b ne fait pas ce qu'un débutant penserait... Mais bon, perso j'évite ce genre de multi-déclarations pour des pointeurs de toute façon.

[m@thieu41]

surtout avec le coding style ridicule en C que les gens utilisent en écrivant int *a au lieu de int* a)

En même temps étant donné que le pointeur ne s'applique que sur a... Après tu peux toujours écrire int* a, mais c'est moins logique. Sinon il aurait fallu que (int*) s'applique à toutes les déclaration suivantes, mais ce n'est pas le cas.
Et comment ferais-tu si tu coulais déclarer plusieurs pointeurs?
int* a,* b,* c?
int* a, *b, *c?
Le premier cas fais moche, le second est illisible.
Le type de la déclaration est int, après on précise qu'on veut récupérer le pointeur... C'est logique du coup de faire int *a.

[Adriweb]

C'est exactement ce que j'ai décris (1ère façon de penser).
Pour ma part, je préfère notamment int* a parce que je raisonne en terme de variable (pointeur ou non, ça on le sait quand on code (et possiblement avec le nom de la variable en question)).
Ca m'est beaucoup moins naturel de penser "*a" est un int que de me demander "qu'est-ce que c'est, 'a' ? => 'a' est un pointeur vers un int". Et c'est pour ça qu'on le déréférence en faisant "*a". Au moins, la séparation est claire.

Et pis bon, libre à vous de faire ceci : int * a

[Hayleia]

Je suis d'accord avec tout ce qui précède la citation suivante.

Concernant le platform.window:invalidate() : si ça ne te plait pas, tu peux très bien mettre screen = platform.window, du coup après tu peux faire : screen:invalidate();

Oui mais il reste le "invalidate"
C'est clair pour tous ceux qui ont déjà utilisé une librairie qui utilise ce mot, mais quelqu'un qui n'a jamais programmé ne comprendra rien à cette ligne. Il ne comprendra rien non plus à mes lignes d'Axe mais encore une fois, on ne parle pas de mes lignes d'Axe. Par contre, il comprendra le code qui déplace un rectangle. Pas le While 1, pas les numéros dans les getKey(), mais il comprendra quand même que ces getKey vérifient l'appui sur des touches, qu'ils font varier la position (X,Y) et que Rect dessine le rectangle (surtout s'ils ont déjà lancé le programme avant d'étudier son code).

Ton argument des espaces entre le "=" est irrecevable : quand on a un grand écran, on ne cherche pas à gagner de la place sur ça (même si ça reste possible).
C'est comme si tu disais que la langue française est illisible parce qu'il y a des espaces entre les mots! Tuemecomprendsvraimentmieuxsijeteparlecommeçasansaccents? Non, d'où l'utilité de mettre des espaces : aérer, et rendre plus lisible.

Pour le "=", à la limite, je veux bien mettre des espaces de chaque côté. Mais franchement.
a = x * 2 + c * 4 - d / 2 est vraiment plus lisible que a = x*2 + c*4 - d/2 ?
Quand à la langue française, aucun rapport. Le "=" fait pour moi office de "séparateur de mot". Je peux donc très bien écrire "a=0" au lieu de "a = 0".

surtout avec le coding style ridicule en C que les gens utilisent en écrivant int *a au lieu de int* a)

En même temps étant donné que le pointeur ne s'applique que sur a... Après tu peux toujours écrire int* a, mais c'est moins logique. Sinon il aurait fallu que (int*) s'applique à toutes les déclaration suivantes, mais ce n'est pas le cas.
Et comment ferais-tu si tu voulais déclarer plusieurs pointeurs?
int* a,* b,* c?
int* a, *b, *c?
Le premier cas fais moche, le second est illisible.
Le type de la déclaration est int, après on précise qu'on veut récupérer le pointeur... C'est logique du coup de faire int *a.

Dans mon paragraphe plus haut, tu dis "on a plein de place". Donc je vais tout simplement écrire ça :

Code: Select all

int* a;
int* b;
int* c;


Notez que je ne fais pas ça que pour les pointeurs, j'ai fait ça pour des "double" une fois, dans un programme que j'ai rendu à mes professeurs, et personne ne s'est plaint du nombre de lignes. Et il n'y avait pas que trois "double".

Quant à int* a, j'ai Excale derrière moi (ça t'apprendra à popcorner ).
Appelons ça la notation 1, et appelons int *a la notation 2.

Dans les deux notations, on est d'accord que "le membre de droite" est de type "le membre de gauche".
Par contre, quand vous écrivez "type objet", vous ne faites pas que dire "objet est de type type", vous déclarez cet objet. Avec "int a", vous déclarez un int nommé a. Avec "int* a", vous déclarez un int* nommé a. Avec "int *a", vous déclarez un int nommé *a ? Non.

C'est encore plus ridicule quand on initialise juste après la déclaration.
Quand on écrit "g = d", g et d sont de même type.
Quand on écrit "type g = d", g et d sont de type type.
Quand on écrit "int* a = malloc(sizeof(int))", tout va bien.
Quand on écrit "int *a = malloc(sizeof(int))", on a le malloc qui est du même type que *a ? Du type int ? Non.

Un problème évident avec la lecture de ce code :
on ne sait pas à quoi correspondent les touches (codes du getKey) !
Autre chose, mais un peu moins important : qu'est-ce que c'est que ce ".AA" en haut tout seul ?

Comme dit plus haut, effectivement, on ne sait pas quelle touche fait quoi avec ces nombres. Mais on comprend quand même qu'on vérifie l'appui des touches pour bouger X et Y.
Quand au ".AA", c'est pas clair dans mon exemple. Mais en fait, la première ligne du code est un point suivi du nom du programme compilé. Dans mes programmes test je mets toujours .AA parce que je m'en fiche, mais dans un vrai programme, n'importe qui est capable de voir que ce qui suit le point est le nom du programme qu'il a lancé avant de s'intéresser à son code source (ce nom n'étant pas AA).

Code: Select all

x,y = 0,0

function on.arrowKey(dir)
    if dir == "left" then
        x = x-1
    elseif dir == "right" then
        x = x+1
    elseif dir == "up" then
        y = y-1
    else
        y = y+1     
    end
    platform.window:invalidate()
end

function on.paint(gc)
    gc:drawRect(x, y, 8, 8)
end

Ben pour moi, ton code ne fait rien. Il initialise x et y, ok. Il déclare deux fonctions, ok. Mais c'est tout, il n'y a pas de code qui dit "on va boucler, vérifier les touches et dessiner", juste deux fonctions.
À la limite, si on réfléchit, on peut se dire que la première fonction s'exécute toute seule quand on appuie sur une touche fléchée avec le on.arrowKey, mais alors la deuxième je ne sais pas du tout.

Mon avis là-dessus est que de la maintenance, il va forcément y en avoir si le projet est suffisamment important où que le code est partagé entre plusieurs personnes etc.

Projet important, non. Par exemple sur Topaze, je fais des mises à jour quand on me parle d'un bug mais c'est tout. Et je n'ai aucun problème à comprendre mon code qui est écrit "de la manière débutante".
Quand au partage, je veux bien. Mais aucun projet Axe n'a jamais été codé par plusieurs personnes. Il n'y a que TinyCraft (premier du nom, pas le mien) qui a essayé, et comme il n'y avait pas vraiment d'organisation, tout le monde est finalement parti.

[m@thieu41]

quelqu'un qui n'a jamais programmé ne comprendra rien à cette ligne

Là je te dirais : quelqu'un qui n'a jamais programmé ne comprendra jamais n'importe quelle ligne de n'importe quel programme, à moins que ce soit du type : demanderAuProgrammeDeLancerLeJeuSnake()
Donc cette ligne est compréhensible, il suffit de s'y connaitre un minimum, mais même un débutant est sensé connaitre un minimum.

a = x * 2 + c * 4 - d / 2 est vraiment plus lisible que a = x*2 + c*4 - d/2 ?

Là je suis d'accord, mais de toute façon je mets a = x*2 + c*4 - d/2 et non pas a = x * 2 + c * 4 - d / 2, mais encore moins a=x*2+c*4-d/2 (ça passe encore, mais selon les cas ça peut devenir illisible ^^).

Déclarer les pointeurs sur plusieurs lignes, pourquoi pas si ça t'arrange, moins je n'y vois pas d'inconvénient, c'est compréhensible et tout.

Pour moi int *a est logique, simplement du fait que int* ne s'applique qu'à la première variable qui suit. Si int* s'appliquait à toutes les variables, pourquoi pas, mais là ce n'est pas le cas, donc on fait avec .