> Le problème c'est plutôt ton bloc de 3-4 écrans que l'indentation type python....
> Personnellement, un bloc qui fait 10 lignes je m'en méfie, qu'il y ai des {} ou non.
Pas forcément... Je me bat depuis longtemps contre les personnes qui considèrent ce genre de choses comme étant absolues, et qui veulent imposer des style de code sans réfléchir...
J'ai deux exemples de code ou j'ai fait des fonctions de 150 à 200 lignes et qui sont bien plus lisible et ou le risque de bug est bien plus faible que leur équivalent découpé en petites fonctions.
1/ L'implémentation de l'algo benson-pass-alive dans un jeu de go : Cet algo nécéssite 6 tableaux temporaires et tout un tas de petites variables qui sont utilisés tout aux long de l'algo.
Il se découpe facilement en 5 ou 6 étapes: calcul des deux premiers tableaux, premier passage sur le goban, mise à jour des deux suivant, itération de l'algo...
La version en une fonction déclare toutes les donnée au début de la fonction, les tableaux étant internes à l'algo se trouvent alloués dans la pile donc les perfs sont meilleures et il n'y a pas à se préoccuper de les désallouer, c'est fait automatiquement à la sortie de la fonction. Les variables gardent le même nom tout au long de l'algo.
Chaque étape est bien séparée des suivantes par un court commentaire qui indique à quelle étape on en est, ce qui permet de se référer à la description de l'algo dans un gros commentaire avant le début de la fonction.
Bref ça ce lit très bien et le code est facilement compréhensible.
La version qui découpe les différentes étapes dans différentes fonction est par contre beaucoup moin lisible, chaque fonction prend une dizaine de paramètres l'algo en lui même se retrouve explosé, de manière logique bien sur mais c'est plus dur à suivre.
Chaque fonction n'est appellée qu'une fois donc il n'y a pas de problème pour inliner le code mais ça reste moche.
Le grand nombre de paramètre des fonctions fait qu'il est facile de ce tromper.
Je vais pas détailler mais c'est beaucoup moins pratique et bien moins facile de comprendre ce qui ce passe vraiment.
Bien sur ont peut aussi faire une structure ou un objet qui contienne toutes les variables et tableaux temporaire, mais dans ce cas la soit on a langage ou il faut gérer explicitement la mémoire et il faut faire une allocation qui coute cher et ne pas oublier le free. Si on a un langage ou la memoire est gérée automatiquement on ne sait plus vraiment ce qui ce passe ni quel est l'impact de l'allocation.
2/ Le même genre de problème dans le calcul de l'espérance pour l'apprentissage d'un modele CRF. La aussi on a besoin de pas mal de tableaux intermédiaires qui sont chiant à faire passer d'une fonction à une autre alors que de simples variables locales sont tellement plus simple et regroupe toutes les étapes de l'algo au même endroit dans l'ordre ou elle sont éffectuées de manière logique et lisible.
Donc même si de manière générale, il faut éviter les fonctions ou indentations longues, ce n'est pas une véritée absolue et parfois un code peut être écrit de manière bien plus sûre, lisible et maintenable et violant les style de code.
Mon code pour l'éxemple deux est une fonction 175 lignes contenant notament une boucle for de 103 lignes. Une autre version du code qui est distribuée sur 5 fonctions fait au total 286 lignes.
Pour avoir discuté avec 3 personne qui ont du utiliser les deux versions, toutes on admis que la première est bien plus compréhensible, et pour l'une d'elle ce fut vraiment très difficile à admettre...
La seule chose avec ce genre de code c'est qu'il faut être très discipliné, avoir des noms pour toutes les variables qui soient parfaitement explicite et cohérent bien séparer toutes les étapes et avoir un gros pavé de commentaire avant la fonction expliquant ce qu'elle fait et comment elle le fait.
Et bien sûr il ne faut utiliser ce genre de chose que lorsque c'est nécéssaire.
[^] # Re: Langage idéal...
Posté par beagf . En réponse au journal Nimrod, ça se rapproche du langage idéal. Évalué à 8.
> Personnellement, un bloc qui fait 10 lignes je m'en méfie, qu'il y ai des {} ou non.
Pas forcément... Je me bat depuis longtemps contre les personnes qui considèrent ce genre de choses comme étant absolues, et qui veulent imposer des style de code sans réfléchir...
J'ai deux exemples de code ou j'ai fait des fonctions de 150 à 200 lignes et qui sont bien plus lisible et ou le risque de bug est bien plus faible que leur équivalent découpé en petites fonctions.
1/ L'implémentation de l'algo benson-pass-alive dans un jeu de go : Cet algo nécéssite 6 tableaux temporaires et tout un tas de petites variables qui sont utilisés tout aux long de l'algo.
Il se découpe facilement en 5 ou 6 étapes: calcul des deux premiers tableaux, premier passage sur le goban, mise à jour des deux suivant, itération de l'algo...
La version en une fonction déclare toutes les donnée au début de la fonction, les tableaux étant internes à l'algo se trouvent alloués dans la pile donc les perfs sont meilleures et il n'y a pas à se préoccuper de les désallouer, c'est fait automatiquement à la sortie de la fonction. Les variables gardent le même nom tout au long de l'algo.
Chaque étape est bien séparée des suivantes par un court commentaire qui indique à quelle étape on en est, ce qui permet de se référer à la description de l'algo dans un gros commentaire avant le début de la fonction.
Bref ça ce lit très bien et le code est facilement compréhensible.
La version qui découpe les différentes étapes dans différentes fonction est par contre beaucoup moin lisible, chaque fonction prend une dizaine de paramètres l'algo en lui même se retrouve explosé, de manière logique bien sur mais c'est plus dur à suivre.
Chaque fonction n'est appellée qu'une fois donc il n'y a pas de problème pour inliner le code mais ça reste moche.
Le grand nombre de paramètre des fonctions fait qu'il est facile de ce tromper.
Je vais pas détailler mais c'est beaucoup moins pratique et bien moins facile de comprendre ce qui ce passe vraiment.
Bien sur ont peut aussi faire une structure ou un objet qui contienne toutes les variables et tableaux temporaire, mais dans ce cas la soit on a langage ou il faut gérer explicitement la mémoire et il faut faire une allocation qui coute cher et ne pas oublier le free. Si on a un langage ou la memoire est gérée automatiquement on ne sait plus vraiment ce qui ce passe ni quel est l'impact de l'allocation.
2/ Le même genre de problème dans le calcul de l'espérance pour l'apprentissage d'un modele CRF. La aussi on a besoin de pas mal de tableaux intermédiaires qui sont chiant à faire passer d'une fonction à une autre alors que de simples variables locales sont tellement plus simple et regroupe toutes les étapes de l'algo au même endroit dans l'ordre ou elle sont éffectuées de manière logique et lisible.
Donc même si de manière générale, il faut éviter les fonctions ou indentations longues, ce n'est pas une véritée absolue et parfois un code peut être écrit de manière bien plus sûre, lisible et maintenable et violant les style de code.
Mon code pour l'éxemple deux est une fonction 175 lignes contenant notament une boucle for de 103 lignes. Une autre version du code qui est distribuée sur 5 fonctions fait au total 286 lignes.
Pour avoir discuté avec 3 personne qui ont du utiliser les deux versions, toutes on admis que la première est bien plus compréhensible, et pour l'une d'elle ce fut vraiment très difficile à admettre...
La seule chose avec ce genre de code c'est qu'il faut être très discipliné, avoir des noms pour toutes les variables qui soient parfaitement explicite et cohérent bien séparer toutes les étapes et avoir un gros pavé de commentaire avant la fonction expliquant ce qu'elle fait et comment elle le fait.
Et bien sûr il ne faut utiliser ce genre de chose que lorsque c'est nécéssaire.