La clarté de certains codes - Page 1

yop,

Ca vous arrive de mettre le nez dans un programme de quelqu'un, disons un projet perso, mais quand même d'une taille respectable, et de vous dire en lisant le code que le programme a l'air tout simple, que la structure a l'air simple, que les problèmes résolus n'en sont finalement pas, tellement les solutions apportées sont simples et élégantes, etc...

Pour moi, c'est ce qui définit un auteur intelligent, maitre de son outil et de son art, c'est cette facilité et cette limipidité qui transparait à chaque ligne de son code, c'est cette façon de mettre des solutions qui paraissent basiques aux problèmes qu'on immaginait complexes, à portée du premier reviewer du dimanche. Ca donne des codes très agréables à lire, émerveillants pour l'esprit.

Et vous, ça vous arrive de tomber sur des programmes de ce genre ? Vous avez des exemples à donner ?

(Mmmm le topic apparaît en double dans yn24 ?)

parcequ'il en existe deux

yes, reporté sur IRC. D'ailleurs, fait étrange, je ne suis pas automagiquement celui-ci, comme ça devrait être pour un topic que j'ai créé.
C'est un peu étrange.

./1 : oui. J'ai plus d'exemples en tête, mais je me suis déjà dit : "bon alors, voyons comment ça marche... huh, il doit manquer une partie du code, c'est pas possible que ça tienne en si peu de lignes... ah ben si, fortiche"

Le moteur d'echecs pour x86 qui tiens en quelques Ko?

J'ai pas regardé les sources, mais y'a des chances que ce soit plus un code compact qu'un code clair, non ?

Je parlais de ces codes qui sont tellement bien architecturés qu'on a l'impression qu'il n'y a presque rien dans les sources, mais qui font plein de trucs.

Voilà, je parle de ça aussi, pas de concours d'obfuscation pour demeurés.
En fait, le sujet m'est venu en tête à cause de la question de squalyl sur Codelite, et j'ai mis un peu le nez dedans pour faire quelques petits patchs, c'est le ressenti que j'en ai eu.

Ce qui est plus courant à mon avis, c'est de chercher dans un projet comment est fait quelque chose de bien précis, et ne jamais trouver tellement les 3 lignes en question sont ensevelies sous des tonnes de couches d'abstraction et d'indirections inutiles.

Ah, le nombre de millions de fois que ça m'est arrivé ça xD

Le moteur d'echec auquel je pense n'était pas lié a un concours d'obfuscation

http://www.pouet.net/prod.php?which=64962

512 Octets en asm x86

Je connaissais, mais je parlais pas de ce genre de soft. "ça marche", mais l'IA est ultra limitée, bref c'est pas intéressant. C'est beau pour une autre raison (la taille).

Et surtout, je trouve pas que le code soit un modèle de clarté (même s'il est commenté).

nitro (./9) :
Ce qui est plus courant à mon avis, c'est de chercher dans un projet comment est fait quelque chose de bien précis, et ne jamais trouver tellement les 3 lignes en question sont ensevelies sous des tonnes de couches d'abstraction et d'indirections inutiles.

, Le nombre de fois ou j'ai eu a faire a un code aussi simple et limpide qu'il devraient l'être sont rares.

Après pour être honète, même si c'est rare, il y a le cas ou on tombe sur un code que l'on trouve inutilement compliqué, qu'on le corrige et qu'au final on se rend compte que la méthode trop simple échoue dans des cas très particuliers, et que s'il était si compliqué, c'est qu'il y avait une bonne raison.

Pour répondre au ./1, oui ça m'est déjà arrivé, même si j'ai plus d'exemple en tête. (Je crois que ça m'a déjà fait ça sur certaines libs JavaScript, mais aussi sur du code en C#)

Mais c'est clair qu'en général, j'aurais plutôt tendance à ./9 …

Le problème du ./9 est effectivement très courant. Cela dit, ce n'est jamais mon code que je trouve trop compliqué, et visiblement il n'y a pas qu'à moi que ça arrive. Sommes-nous aveugles par rapport au bordel dans notre propre code? Ou alors les complicateurs ne postent-ils pas à ce sujet tout simplement?

Il y a sûrement des deux.

Oui, moi aussi la notion de bordel me parait très subjective. Il m'arrive très souvent de voir du code qui me semble bordélique au boulot, et il arrive aussi qu'avec l'auteur à côté pour expliquer je vois une logique apparaître qui m'aurait totalement échappé sinon (mais bon l'argument de la subjectivité étant plus important, même après coup ça me semble quand même toujours un peu bordélique ).

faut dire qu'il y a globalement peu de moyens d'expliquer du code, je trouve.

Un bon article scientifique aura une intro, des sections, des résumés de chaque sections, bref des moyens simples de comprendre la structure globale. Ce n'est pas évident de faire ça avec un code, sauf à faire une doc spécifique (en-dehors du code).

x 10

C'est pour ça que la présentation contextuelles des aides a une grande importance pour moi. Quand je passe ma souris sur un nom de fonction, je veux avoir son prototype, le résumé de sa doc, le fichier où elle est déclarée et définie, et aller à sa doc complète en appuyant sur F1 (dans le genre, Qt Creator fait ça plutôt pas mal).

Quand même, si tu sépare bien ton code en plusieurs fonctions lorsqu'il y a besoin et que tu nomme bien tes fonctions et tes variables, ça aide bien à la lisibilité. (Enfin après y'a des soucis d'architecture, mais on retombe dans le cas cité en ./9)
Tu arriveras jamais à la lisibilité d'un bouquin ou d'une publication, parce que par nature, le flux d'exécution d'un programme non-trivial est non-linéaire (arborescent, je dirais), mais tu peux essayer de t'en approcher un peu.

Faire des paragraphes dans les fonctions me semble être une bonne pratique.
Et limiter la portée des variables également.
Après, il y a le bon sens, la rigueur et le talent du codeur, c'est clair.

Pen^2 (./22) :
Faire des paragraphes dans les fonctions me semble être une bonne pratique.

Yep, j'essaye de faire ressortir ça visuellement avec les styles de commentaires par exemple.

Moi je ne commente pas beaucoup, mais rien qu'en sautant des lignes c'est déjà pas mal.

GoldenCrystal (./21) :
Quand même, si tu sépare bien ton code en plusieurs fonctions lorsqu'il y a besoin et que tu nomme bien tes fonctions et tes variables, ça aide bien à la lisibilité. (Enfin après y'a des soucis d'architecture, mais on retombe dans le cas cité en ./9)Tu arriveras jamais à la lisibilité d'un bouquin ou d'une publication, parce que par nature, le flux d'exécution d'un programme non-trivial est non-linéaire (arborescent, je dirais), mais tu peux essayer de t'en approcher un peu.

Ça marche bien au sein d'un fichier, mais pas tellement quand tu as pas mal de fichiers.

Je me demande ce que pourrait donner un IDE permettant de la mise en forme (texte en gras, différentes tailles de texte, encadrement, etc.)

(heu... faire une conception?)

Et on fait ça comment, pour faire ça bien, maintenable, aussi bien pour soi que pour ceux qui voudraient y mettre le nez, svp ?

(Heu... avec beaucoup de la sueur et un peu de volonté ?)

PpHd (./26) :
(heu... faire une conception?)

Par où commences-tu quand tu ouvres un code un peu complexe ? Comment deviner par où commencer, que telle classe est plus importante qu'une autre ?