Pour l'histoire des accolades : arrive-t-on réellement a un code où il n'y a jamais deux instructions dans un if/else/autre ? Si oui, alors il peut être envisageable de se passer d'accolades. Mais ça + une largeur de ligne faible, ça me semble étrange. Mais peut-être est-ce possible, auquel cas c'est intéressant ;)
C'est un exercice que je trouve intéressant. Je n'ai pas encore rencontré de cas où c'était impossible, mais je n'ai pas non plus souvent codé des trucs extrêmement complexes.
Il y a des langages où c'est beaucoup plus facile. En premier, Forth, puisque c'est de là que j'ai tiré cette pratique. Ensuite, les langages objets, parce qu'on peut passer l'information de manière peu verbeuse (le contexte de l'objet est partagé entre les méthodes, pas besoin de passer cinquante arguments). Dans un langage comme le C, ça devient plus compliqué de faire tenir le code sur une seule ligne.
Pour tenir sur des lignes courtes, il faut des noms courts. C'est facile en Forth ou on peut redéfinir un mot sans affecter le comportement des fonctions précédemment définies. C'est possible avec les langages objets, parce qu'il est possible de trouver des noms courts quand le projet est bien structuré : une variable est un nom, une méthode est un verbe, et effectuer une action consiste à écrire une phrase. Et on peut toujours découper un texte en phrases courtes. Mais là encore, c'est possible parce qu'un même mot peut avoir différentes significations (suivant le contexte, ici, l'objet dans lequel on travaille). Ceci-dit, un nom idéal est un nom composé d'un seul mot. J'atteins rarement ce stade avec les langages objets, comme on peut le voir dans le code que j'ai présenté. Mais la limite de taille m'oblige à me triturer suffisamment les méninges pour éviter le traditionnel piège du « FactoryOfSingletonFactoryOfUserComment ».
[^] # Re: Code auto-documenté
Posté par daeldir . En réponse au journal To comment or not to comment. That is the question.. Évalué à 2.
C'est un exercice que je trouve intéressant. Je n'ai pas encore rencontré de cas où c'était impossible, mais je n'ai pas non plus souvent codé des trucs extrêmement complexes.
Il y a des langages où c'est beaucoup plus facile. En premier, Forth, puisque c'est de là que j'ai tiré cette pratique. Ensuite, les langages objets, parce qu'on peut passer l'information de manière peu verbeuse (le contexte de l'objet est partagé entre les méthodes, pas besoin de passer cinquante arguments). Dans un langage comme le C, ça devient plus compliqué de faire tenir le code sur une seule ligne.
Pour tenir sur des lignes courtes, il faut des noms courts. C'est facile en Forth ou on peut redéfinir un mot sans affecter le comportement des fonctions précédemment définies. C'est possible avec les langages objets, parce qu'il est possible de trouver des noms courts quand le projet est bien structuré : une variable est un nom, une méthode est un verbe, et effectuer une action consiste à écrire une phrase. Et on peut toujours découper un texte en phrases courtes. Mais là encore, c'est possible parce qu'un même mot peut avoir différentes significations (suivant le contexte, ici, l'objet dans lequel on travaille). Ceci-dit, un nom idéal est un nom composé d'un seul mot. J'atteins rarement ce stade avec les langages objets, comme on peut le voir dans le code que j'ai présenté. Mais la limite de taille m'oblige à me triturer suffisamment les méninges pour éviter le traditionnel piège du « FactoryOfSingletonFactoryOfUserComment ».