Discussion :

[Mat_DZ]

Bonjour à tous !
Je voulais proposer un petit sondage afin de connaître l'opinion d'un maximum de personnes.
La mise en place de fonctions est on ne peut plus pratique pour permettre une portabilité et une réutilisation maximum de notre code, nous permettant ainsi des gains de temps considérables dans le développement de nos applications à venir.
J'aurais voulu savoir si, selon vous, ça valait le coup de tout programmer par des fonctions, si cela était possible, les fonctions incontournables, et tout vos petits trucs et astuces vous permettant de gagner du temps par la mise en place de fonctions.
Toute idée et opinion est la bienvenue !

[Caine]

Bonjour, le sujet est vaste!

Il est intéressant de mettre dans des fonctions, tout ce qui est utiliser à plusieurs endroits d'un projet.

Les types abstraits de données comme liste chaînée, arbres...et bien d'autres, sont à regouper dans des librairies.

Mais il faut garder à l'esprit que le saut à une fonction est consommateur de temps processeur et donc moins rapide que du code "inline".

Penses-tu qu'il soit possible de rentrer dans les détails sans écrire un livre

[khayyam90]

J'ai connu des personnes qui voulaient tout mettre en fonction. Même des fonctions qui ne comprenaient qu'une seule instruction. Selon eux, ça rendait plus clair.

Pour ma part, je découpe en fonction tout ce qui se rapporte à un même traitement, toutes les opérations qui vont ensemble. La question se pose ensuite sur la séparation des fonctions. Pour celà, je regarde si un code est réutilisé autre part dans mon code, ou bien selon le nom de la fonction ; sachant que j'essaie toujours de bien choisir mes noms de fonctons.

J'accorde beaucoup d'importance au nom d'une fonction et à son interface. Je trouve que c'est primordial pour une réutilisation rapide et facile d'un code, que ça soit par moi ou bien par quelqu'un d'autre.

Ensuite, si on vient par une approche objet, la réflexion est plus élémentaire. Il faut repérer les traitements qu'on peut appliquer à des objets sans se soucier des autres classes. Ca permet de concevoir chaque classe indépendamment des autres.

La mise en fonction permet aussi de rajouter une couche d'abstraction sur un code trop bas niveau (ou tout simplement pour aborder différemment un même traitement).

[aziz jim]

personnellement j'utilise c++
et avec ce langage ( poo) il est impossible de parler de développement sans parler de fonctions

[zooro]

Moi je serais plus partisan de l'utilisation intensive des fonctions et des macros.
Quitte à utiliser le mot clé "inline" si possible.

Evidemment, ça dépend aussi du contexte, du langage, etc.
Mais en général, je trouve que si le code est découpé en fonctions, il est plus facile à comprendre, à débugger, et à maintenir.

En ce moment, je bosse sur un gros projet conçu et développé initialement à l'étranger, et où les quelques fonctions utilisées font plus de 10.000 lignes chacune, avec des fichiers source de plusieurs mégas... Et les noms de fonction ne permettent pas de savoir ce qu'elles font. Bref, l'horreur !

[Alp]

Penses-tu qu'il soit possible de rentrer dans les détails sans écrire un livre

Pourquoi ne pas en écrire un?
Sur l'organisation du code. Ca peut être sympa

AMHA, une fonction doit réaliser une "action", une "tache", pas plus, pas moins.
Bien sur, pour éviter le coup de l'appel, on peut toujours tenter de l'inliner(dans certains langages), ou bien si l'on n'appelle la fonction qu'une seule fois, autant écrire le code directement là où elle est appelée.

[2Eurocents]

A mon avis, la fonction a deux objectifs majeurs :

• Factoriser du code, c'est à dire rassembler dans un lieu unique les répétitions de blocs de code, quitte à paramétrer les dissimilitudes. Cela facilite la maintenance et les évolutions. Il va de soit que le coût de l'appel de fonction doit être contrebalancé par l'importance du code factorisé : ça ne sert à rien de se faire une fonction d'incrémentation sous prétexte qu'on arrête pas d'incrémenter ses variables
• Clarifier la structure du code, en délèguant les traitements spécifiques à une entité spécifique. Cet objectif est, pour moi, poussé à l'extrême dans la notion de méthode propre à la programmation orientée objet : la fonction est alors attachée aux données qu'elle manipule et la manipulation des données n'est plus possible sans usage de la fonction.

De ces deux objectifs primordiaux, il peut se dégager une possibilité de ré-utilisation du code, mais à la condition que les fonctions soient bien écrites

Chacun de ces deux objectifs a un revers à sa médaille :

• Le coût des appels lors de l'abus de fonctions pour tout et n'importe quoi.
• Le manque de clarté pour comprendre le code lorsque l'on a abusé des fonctions et que les chaque fonction n'est plus qu'un empilement d'appels aux autres.

Un bonne fonction doit donc contenir un minimum de "logique", de "structure", pour être un ensemble pertinent.

[zooro]

lorsque l'on a abusé des fonctions

Et oui, les fonctions, c'est bien !
En abuser, ça craint !


Plus sérieusement, c'est comme tout, il faut faire un compromis entre le tout fonction et le "zéro fonction".
C'est aussi un peu ça la différence entre un bon et un mauvais développeur ! (petite référence aux Inconnus )

[Caine]

Je pense qu'il est inutile de déterminer une recette prémachéepour cette question.

Mais il me paraît utile dse rappeler la motivation de la programmation fonctionnelle (et procédural):

- Capitaliser les codes sources afin de réduire la taille de l'xécutable.
- Centraliser les traitements récurants afin de faciliter la maintenance évolutive et corrective.
- Améliorer la lisibilité des algorithmes complexes, il est admit que dépasser 2 écrans pour la lecture d'une fonction est difficile. Et pourant ça arrive si souvent...
-Réutiliser le code source entre projet
-Réduire l'impact des tests en découpant son application.

[edit]
Je n'avais pas eu le temps de poster avant, je suis redondant avec 2Euro, sorry

[Jacti]

[quote=khayyam90]J'ai connu des personnes qui voulaient tout mettre en fonction. Même des fonctions qui ne comprenaient qu'une seule instruction. Selon eux, ça rendait plus clair.(/quote]
Oui bien sûr qu'il faut tout mettre en fonction.
Il y a de nombreuses fonctions qui ne contiennent qu'une seule instruction en POO : les sélecteurs et les modificateurs. Les sélecteurs contiennent, en général, la seule instruction return comme dans ce code C++, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 int Registre::eval() const
  {return no_reg;}
   
  int Registre::val() const
  {return Reg[no_reg];}

Je ne vois pas ce qu'il y a de rédhibitoire, au contraire !

Le code ci-dessus est d'ailleurs tiré d'un simulateur de processeur (Motorola 68000) et la plus grosse fonction fait... 4 lignes !
Inutile de dire que ce code est totalement évolutif et très facilement maintenable.

Par ailleurs

Un bonne fonction doit donc contenir un minimum de "logique", de "structure", pour être un ensemble pertinent.

Et bien non, mon exemple précédent montre le contraire. D'ailleurs, en C++, le but du jeux, pour les constructeurs, est que leur corps soit vide. Ceci est possible en utilisant la syntaxe d'initialisation.

Enfin, en faisant de très petites fonctions, comme elles sont toutes "online", on ne perd rien en performance et on gagne en clarté.
Le pire, c'est de faire des "petites" fonctions mais suffisamment grosses quand même pour qu'elles ne puissent pas être "online".

Jacti

[HanLee]

"online" -> "inline"

[Jacti]

"online" -> "inline"

A quoi pensais-je ???
Merci

Jacti

[InOCamlWeTrust]

Moi je pense que c'est une question qui n'a aucun sens.

Dans certains langages, la notion même de fonction est absente, et dans d'autres (comme Haskell par exemple), elle est omniprésente.

Je trouve aussi l'argument : "un appel de fonction, c'est très cher" assez mal justifié. Là encore, suivant les langages, les algorithmes et la façon de programmer, un appel de fonction peut être plus ou moins coûteux, et étant donné que la fonction permet d'abstraire, on a parfois intérêt à faire appel aux fonctions plutôt qu'à se programmer une pseudo-récursivité au moyen de piles gérées manuellement.

La sémantique dans ce genre de domaine apporte beaucoup de réponses intéressantes. En effet, les langages dont le contexte d'évaluation est complètement déterminé offrent de bien meilleures possibilités d'optimisation que les langages (comme Fortran) avec lesquels il est possible de sortir violemment d'une procédure et se retrouver à perpetes-les-oies-d'où-on-avait-appelé-la-procédure. Ici, les fonctions jouent un grand rôle car ce sont elles qui permettent d'encapsuler et de maintenir le contexte d'évaluation déterminé.

Comme souvent en langages de programmation, il n'existe pas d'idée fixe.

[gorgonite]

Moi je pense que c'est une question qui n'a aucun sens.

un peu sévère... tout le monde n'utilise pas de langages à haut niveau d'abstraction, à paradigme complètement différent, n'est pas non plus expert en compilateurs

dans la majorité des cas, les fonctions (ou leurs equivalents... cf asm) existent

En effet, les langages dont le contexte d'évaluation est complètement déterminé offrent de bien meilleures possibilités d'optimisation que les langages (comme Fortran) avec lesquels il est possible de sortir violemment d'une procédure et se retrouver à perpetes-les-oies-d'où-on-avait-appelé-la-procédure.

sans vouloir troller... t'es à côté de la plaque

les compilateurs fortran "vieux standards" sont parmi les plus agressifs... et les perfs peuvent dépasser le c sans difficultés

Je trouve aussi l'argument : "un appel de fonction, c'est très cher" assez mal justifié (...) plutôt qu'à se programmer une pseudo-récursivité au moyen de piles gérées manuellement.

tout dépend du langage, des compilos, etc
ce n'était pas le cas il n'y a pas si longtemps... et c'est encore le cas avec certains compilateurs "peu malins" pour dérécursifier

[InOCamlWeTrust]

un peu sévère...

Oui, c'est vrai, c'est un peu sévère.

sans vouloir troller... t'es à côté de la plaque

Pourquoi ?

Pour ce qui est des compilateurs Fortran, j'attends toujours d'en voir un vrai bon qui produise un code de qualité.

L'année dernière, pour un projet long en algèbre linéaire numérique, on avait utilisé la notation vectorielle pour faire des opérations sur les matrices et les vecteurs. C'était le moment d'optimiser, du point de vue du compilateur, car ce genre de notation permet de se libérer justement des contraintes imposées par le programmeur. En remplaçant ces notations vectorielles par une simple boucle "DO I = 1, ... END DO", on gagnait 30% en temps d'exécution !!! Ca c'est ce que l'on appelle de l'optimisation agressive !!!

Pour ce qui est de la récursivité, les compilateurs dérécursifient bien les fonctions récursives terminales ; par contre, pour les non terminales... et il ne faut pas penser que des appels récursifs sont plus chers qu'une gestion de pile à la main : une instruction assembleur "PUSH" prend toujours moins de temps qu'un empilement de paramètres via des opérations plus élémentaires... le tout concerne surtout le nombre de paramètres et la façon dont on peut optimiser le tout. Si le corps de la fonction est important, alors on ne gagne rien à dérécursifier ; par contre, si il est petit, ça peut-être intéressant car les optimisations du corps du traitement peuvent se combiner avec celles touchant à la partie consacrée à la gestion de la pile.

[Jacti]

Pour ce qui est de la récursivité, les compilateurs dérécursifient bien les fonctions récursives terminales ; par contre, pour les non terminales...

La récursion terminale est facilement dérécursivable car il suffit de la transformer en boucle (comme factorielle, par exemple).
La récursion non terminal, c'est plus difficile lorsque la fonction n'est pas récursive primitive car il faut, en plus, générer la gestion de la pile (fonction d'Ackermann, par exemple).

Pour répondre à d'autres messages concernant la soi-disant performance des compilateurs Fortran, il me semble que ce sont des idées toutes faites et qu'il faut regarder au cas par cas chaque compilateur pour voir son "intelligence" concernant les optimisations.
Quoi qu'il en soit, considérer, aujourd'hui, qu'un appel de fonction est coûteux, relève plutôt du réflexe du "vieux" programmeur en assembleur que d'une attitude responsable et actuelle.
Il n'y a que certains cas bien spécifiques où la différence aura son importance

[Jacti]

Ce n'est pas toi que je citais mais bien InOCamlWeTrust.
Excusez-moi tous deux.

Jacti

[mhooreman]

Pour faire bref, j'utilise les conseils d'un certain Linus Torvalds qui conseille de faire des fonctions courtes qui ne font qu'une seule chose et qui s'appellent bien sur entre elles.

Reste à savoir si j'ai bien compris ce qu'il a voulu dire...

[InOCamlWeTrust]

C'est aussi l'avis de Kernighan et Ritchie (enfin, c'est surtout le leur, je pense !)... mais je ne suis pas d'accord avec ce point de vue : c'est une question qui est trop dépendante du langage, et morceler un programme à outrance peut vite se révéler préjudiciable, tant en termes de performances qu'en termes de maintenabilité de code, pour le C.

[Jacti]

morceler un programme à outrance peut vite se révéler préjudiciable, tant en termes de performances qu'en termes de maintenabilité de code, pour le C.

Je vais donner des chiffres qui résultent d'un audit (avec Logiscope) sur une application Java d'environ 150 000 instructions. L'application doit être très fiable, facilement évolutive et maintenable.
Voici les chiffres :
- Nombres de méthodes : plus de 26 000
- Nombre moyen d'instructions par méthode : légèrement supérieur à 5 (oui cinq !)
- Pourcentage de méthodes n'excédant pas 20 instructions (ce qui était recommandé par l'assurance qualité du projet) : 95,5 % !!

Au vu des chiffres, on peut considérer que l'application est extrêmement morcelée et pourtant, tant les mainteneurs que les développeurs des nouvelles versions considèrent que l'application est extrêmement bien conçue (ce qu'a d'ailleurs fait ressortir l'audit) et ils s'y retrouvent facilement.

Par ailleurs, il ne faut pas oublier l'effort de test (en particulier les tests unitaires). Plus une fonction est grosse, plus le nombre de chemins à tester sera grand (on compte, en moyenne, un test conditonnel toutes les 5 instructions). La complexité statique (sans son exécution) d'une fonction se mesure à l'aide du nombre cyclomatique (c'est le nombre de conditions + 1). Dans le projet mentionné, les fonctions devaient avoir un nombre cyclomatique inférieur à 10 (ça limite singulièrement leur taille !).

Je suis donc totalement opposé à l'idée que l'utilisation à outrance des fonctions est une mauvaise chose, bien au contraire car cela facilite la réutilisation, on n'est pas obligé de tout recompiler à la moindre modif, etc.
Quant aux performances, une partie de cette application concerne du temps réel !!!