Pour ajouter mon grain de sable, une fonction qui prends 15 paramètres, il y en a généralement 10 de trop*.
Si vraiment il faut passer X ou Y argument a chaque fonctions, il est préférable* de les conserver dans une structure/objet et de ne passer que cet objet et non la dizaine.

Ca reviens un peu a la classe "application" ou "jeu".

Sinon c'est aussi peut être un signe que le design de l'application n'est pas optimal, peut etre que les fonctions qui prennent l'objet/structure en question devrait faire partit du dit objet? Ou alors que ces fonctions fassent partit d'un objet avec un pointeur dans ses propriété vers l'objet passé en paramètre partout?

Le C++ à cette fâcheuse tendance a mélanger le fonctionnel et l'objet, la ou le C#, ObjC (pur) et Java sont bien plus orienté Objet et le fonctionnel a moins de place) et on a tendance a mélanger les deux, je ne pense pas que ca soit une bonne chose.

A moins de s'interfacer avec une lib existante, si on fait du C++ il faut proscrire au maximum la programmation type fonctionnelle, sinon autant faire du C* !

* ceci est bien sur mon avis, et je le partage avec moi meme!

flanker (./16) :

Zeph (./29878) :
moi j'aime bien ce qui est explicite y compris pour les dépendances

(et je déteste encore plus quand même un IDE est incapable de savoir d'où vient un élément)

Exemple de code recent ou j'ai essaye de rentrer et impossible (et meme avec un IDE potable): DCC et DisC deux exemple de code (en C++) a vomir, et quasi impossible a suivre dans y passer des nuits blanches, je n'ai, ni pour l'un ni pour l'autre encore reussi a trouver exactement comment il lis les fichiers en entrée. Un des deux me lit des valeurs fantaisistes dans les fichiers binaires je n'ai toujours pas trouvé pourquoi (pas la faute d'avoir utilisé un debugger la plongé dans le code se fait a travers 5 ou 6 couche dont implementation "perso" (et foireuse) des chaines d'un coté et du Qt (gerbatoire car pas utilisé pour faire de l'UI, juste remplacer des trucs simples a faire) de l'autre. (et ce sont les deux seul décompilateur compatible x86 16bit que j'ai trouvé et qui sont sensé fonctionner sur des OS non daté)

Si vous avez quelques heures a tuer aller regarder la classe "string" de disc ca vaux le détour... :/

(désolé je disgress pas mal la pour le coup sur DCC/DisC je voulais juste parler de l'imbrication et le coté mal pensé d'un projet peuvent le rendre incomprehensible)