écriture concise c'est beau
Bonjour,
Avant de me lancer dans l'écriture d'une nième fonction,
est-il possible de réduire ces 4 lignes 5,7,9,11 en une(à part les ajouter les unes au bout des autres!!!)
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
string fonctionG(string H)
{
//ligne d'initiation de la fonction A
string utilPrm,prmUtiUn,prmUtiDeu,prmUtiTroi,prmUtiQuat;
//la fonction A
utilPrm=FcPrmUti(prmUtiUn,prmUtiDeu,prmUtiTroi,prmUtiQuat);
//lignes d'initiations de la fonction B
string Mop,mopUn,mopDeu,mopTroi,e="e!",z="z!";
//la fonction B
mopUn=prmUtiDeu;mopDeu=e+__func__; Mop=FcMo(mopUn,mopDeu,mopTroi);
return H;
} |
elles sont contenues dans une fonction par exemple.
les inclure dans une fonction C va quand même se terminer par 2 lignes:bénéfice 4 lignes origine = 2 lignes finales,maigre gain.
Si pas possible c'est pas grave.:roll:
A+++ en attendant plus chaleureux.
... mais souvent dangeureux...
Salut,
Il ne faut pas confondre "écriture concise" et obfuscation !!!
Limiter le nombre de lignes dans une fonction ne sert souvent... qu'à rendre le code plus difficilement compréhensible ("obfusqué") sans apporter de réel bénéfice en terme d'exécution.
Un simple exemple tiré de ta première ligne de code:
Code:
string utilPrm,prmUtiUn,prmUtiDeu,prmUtiTroi,prmUtiQuat;
C'est très bien, cela tient sur une seule ligne de code, mais...
tu n'as strictement aucune différence, en terme de performances, entre cette ligne de code et le code
Code:
1
2
3
4
5
| string utilPrm;
string prmUtiUn;
string prmUtiDeu;
string prmUtiTroi;
string prmUtiQuat; |
Par contre, à la lecture (et il faut savoir qu'un code est beaucoup plus souvent lu que compilé ;)), l'utilisateur saura directement de combien de chaines de caractères il dispose et ne risquera pas d'en oublier une qui est "cachée" entre deux autres.
Sous prétexte de concision, tout ce que tu as réussi à faire avec le code tel que tu présentes, c'est à le rendre plus difficile à comprendre et à suivre!
Et il ne faut pas croire que ce n'est le cas que "pour les autres", car le premier des autres qui devra relire le code, c'est sans doute toi, plus tard, parce qu'il faudra apporter des modifications ou corriger un bug.
Le problème, c'est que, le temps ayant passé, tu ne te souviendras plus de la logique que tu voulais mettre en oeuvre, et que si le code n'est pas "directement compréhensible" sans devoir commencer par traquer les ",", tu vas perdre énormément de temps pour rien !
Honnêtement, je connais des chefs de projets qui ne se gèneraient pas pour virer un fichier contenant un tel code (ou pour revenir à la version précédante) et pour t'obliger de le réécrire de manière lisible.
Maintenant c'est toi qui vois, mais, avant de vouloir faire un code concis, veilles :
- à faire en code lisible
- à faire un code qui compile (en gardant 1)
- à faire un code qui fait ce que tu attends de lui (en gardant 1 et 2)
- à optimiser tes algorithmes en terme de performances (en gardant 1, 2, et 3)
