Tout ce qui selon vous doit passer par des fonctions

**Mat_DZ** · 06/09/2006, 09h08

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** · 06/09/2006, 13h17

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** · 06/09/2006, 18h01

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** · 07/09/2006, 15h16

personnellement j'utilise c++

et avec ce langage ( poo) il est impossible de parler de développement sans parler de fonctions

**zooro** · 07/09/2006, 15h29

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** · 09/09/2006, 11h12

Envoyé par Caine

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** · 13/09/2006, 10h25

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** · 13/09/2006, 11h28

Envoyé par 2Eurocents

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** · 13/09/2006, 13h39

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

**mhooreman** · 26/10/2006, 15h28

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** · 26/10/2006, 17h24

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** · 27/10/2006, 14h09

Envoyé par InOCamlWeTrust

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 !!!

**gorgonite** · 27/10/2006, 20h18

attention, ça s'est du code objet pour consultants...

**InOCamlWeTrust** · 06/11/2006, 23h04

Envoyé par Jacti

application Java d'environ 150 000 instructions

Envoyé par Jacti

- Nombres de méthodes : plus de 26 000

Envoyé par Jacti

- Nombre moyen d'instructions par méthode : légèrement supérieur à 5

Envoyé par Jacti

- Pourcentage de méthodes n'excédant pas 20 instructions (ce qui était recommandé par l'assurance qualité du projet) : 95,5 % !!

Tu me confortes, là : J'AI PAS ENVIE D'ETRE CONSULTANT INFORMATIQUE !

Sans déconner : ils ont vraiment dû se faire chier à compter tout ça, comme si on n'avait rien d'autre à foutre (à moins que ce soit fait automatiquement) ! La prochaine fois je compterai le nombre moyen de caractères par catégorie d'identificateurs... je suis sûr que je vais exploser le record !

N'y vois aucune critique dans mes propos : juste une plaisanterie.

Par contre, sur le fait que l'application soit maintenable, je pense que ni les développeurs ni les mainteneurs (qui sont en fait les développeurs des versions ultérieures) n'oseraient dire que leur truc N'EST PAS maintenable... juste une vague impression, comme ça... j'ai pas encore vu de personne descendre (surtout auprès de sa boîte ou de consultants externes, ce qui serait encore pire) son propre bébé... surtout si il fait des milliards de lignes de code.