J'ai pas compris ce que tu voulais montrer dans ton exemple
Dans cet exemple, la partie interessante est planquee a 3 niveau d'indentation, dans 2 if. ton code gestion du cas ou tu ne veux rien faire est melange avec celui ou tu fais effectivement qqchose. Dit autrement, c'est beaucoup plus simple a relire un code qui dit "valide tes input et annule tout si ca va pas, puis fait qqchose", plutot que "si des conditions sont verifiees, alors fait ca, et suit toute la fonction pour apprendre toute a la fin que si pointeur est nul, alors on return la valeur qui a ete sete par defaut 20 lignes plus haut.".
Ton code est plus robuste aussi, tu risques pas de faire une connerie si t'es deja sorti de la fonction. Plus t'as de code entre la creation d'une variable et son return, plus t'as de chance de faire de la merde avec, c'est une variante du concept de "les seuls bugs que t'aura pas sont dans du code que t'as pas ecrit".
Je ne vois pas de cas où tu fais quelque chose de si secret que personne d'autre que ta fonction doit savoir ce que c'est (on parle de fonctions pures dans l'énorme majorité des cas)
Sans etre secret, on peut etre sympa pour ceux qui passent derriere et eviter de leur laisser une tonne de fonction a noms abscons qui ne sont appelees qu'a un seul endroit.
Ça n'oblige l'utilisateur à aller voir le code de la méthode que si tu n'a pas documenter la méthode, que tu n'a pas de convention pour ça et que ton langage ne t'aide pas.
Si t'ecris du code trivial tout seul dans ton coin, oui, c'est sur. mais c'est pas un cas tres pertinent. Les conventions, faut bien relire le code pour s'assurer qu'elle a bien ete suivie. Et mon langage m'aide beaucoup pour ce que je fais, merci bien, mais il ne resoud pas tous les problemes.
D'expérience dans la majorité des cas tu peux découper.
Ben d'experience, c'est pas le cas. J'ai des controlleurs qui font 80-100 lignes dans -viewDidLoad, et ya pas grand chose que je puisse y faire, a part dire au gars du produit d'aller se faire cuire un oeuf. J'ai essaye de les couper "setupThis, setupThat", et au final t'as un setup qui depend du resultat d'une operation au dessus, et t'as un gros merdier sur les bras. Soit t'as des signatures a la con, soit t'as une imbrication d'appel de fonction douteuses. Dans les deux cas, le code qui t'interesse est eparpille, et t'as au final rien gagne du tout.
[^] # Re: Rust vs Go
Posté par groumly . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 4.
Dans cet exemple, la partie interessante est planquee a 3 niveau d'indentation, dans 2 if. ton code gestion du cas ou tu ne veux rien faire est melange avec celui ou tu fais effectivement qqchose. Dit autrement, c'est beaucoup plus simple a relire un code qui dit "valide tes input et annule tout si ca va pas, puis fait qqchose", plutot que "si des conditions sont verifiees, alors fait ca, et suit toute la fonction pour apprendre toute a la fin que si pointeur est nul, alors on return la valeur qui a ete sete par defaut 20 lignes plus haut.".
Ton code est plus robuste aussi, tu risques pas de faire une connerie si t'es deja sorti de la fonction. Plus t'as de code entre la creation d'une variable et son return, plus t'as de chance de faire de la merde avec, c'est une variante du concept de "les seuls bugs que t'aura pas sont dans du code que t'as pas ecrit".
Sans etre secret, on peut etre sympa pour ceux qui passent derriere et eviter de leur laisser une tonne de fonction a noms abscons qui ne sont appelees qu'a un seul endroit.
Si t'ecris du code trivial tout seul dans ton coin, oui, c'est sur. mais c'est pas un cas tres pertinent. Les conventions, faut bien relire le code pour s'assurer qu'elle a bien ete suivie. Et mon langage m'aide beaucoup pour ce que je fais, merci bien, mais il ne resoud pas tous les problemes.
Ben d'experience, c'est pas le cas. J'ai des controlleurs qui font 80-100 lignes dans -viewDidLoad, et ya pas grand chose que je puisse y faire, a part dire au gars du produit d'aller se faire cuire un oeuf. J'ai essaye de les couper "setupThis, setupThat", et au final t'as un setup qui depend du resultat d'une operation au dessus, et t'as un gros merdier sur les bras. Soit t'as des signatures a la con, soit t'as une imbrication d'appel de fonction douteuses. Dans les deux cas, le code qui t'interesse est eparpille, et t'as au final rien gagne du tout.