Je crois qu'une partie de la discution t'a échappé. Ce que je suis c'est qu'il faut garder ses méthodes aussi courtes/simples que possible et réduire autant que possible le nombre de return.
Donc non il n'y a pas 15Mio de code entre une assignation et le retour parce que les méthodes sont courtes.
Au niveau qualité du code, l'utilisation de méthodes quand c'est bien fait permet de gagner en abstraction et de rendre le code bien plus lisible (le code informe sur le comportement métier recherché et pas sur une série d'actions bas niveau). On gagne aussi car on peut tester plus facilement le code et, si on prend le temps de faire du refactoring régulièrement, on peut gagner en réutilisation. En fin on adopte une vision API, ce qui améliore la maintenabilité.
Ça demande à se poser la question des responsabilités et on segmente un peu plus notre code et on regroupe plus facilement le code d'une même responsabilité. Ça permet de mieux repérer les problèmes de couplages (c'est ce dont tu parles quand tu dis qu'on se retrouve avec pleins de méthodes pour celui qui passe après).
J'ai pas compris ton argument qui dit que l'on ne documente et suit des conventions que lorsque l'on écris du code trivial dans son coin. C'est exactement l'inverse.
Pour ton laïus sur les contrôleurs. C'est justement un cas de code qui va manipuler potentiellement une bonne partie de l'application et qui devrait utiliser que du code de très haut niveau.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rust vs Go
Posté par barmic . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 4.
Je crois qu'une partie de la discution t'a échappé. Ce que je suis c'est qu'il faut garder ses méthodes aussi courtes/simples que possible et réduire autant que possible le nombre de return.
Donc non il n'y a pas 15Mio de code entre une assignation et le retour parce que les méthodes sont courtes.
Au niveau qualité du code, l'utilisation de méthodes quand c'est bien fait permet de gagner en abstraction et de rendre le code bien plus lisible (le code informe sur le comportement métier recherché et pas sur une série d'actions bas niveau). On gagne aussi car on peut tester plus facilement le code et, si on prend le temps de faire du refactoring régulièrement, on peut gagner en réutilisation. En fin on adopte une vision API, ce qui améliore la maintenabilité.
Ça demande à se poser la question des responsabilités et on segmente un peu plus notre code et on regroupe plus facilement le code d'une même responsabilité. Ça permet de mieux repérer les problèmes de couplages (c'est ce dont tu parles quand tu dis qu'on se retrouve avec pleins de méthodes pour celui qui passe après).
J'ai pas compris ton argument qui dit que l'on ne documente et suit des conventions que lorsque l'on écris du code trivial dans son coin. C'est exactement l'inverse.
Pour ton laïus sur les contrôleurs. C'est justement un cas de code qui va manipuler potentiellement une bonne partie de l'application et qui devrait utiliser que du code de très haut niveau.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)