Ça ne change pas grand chose au final, ce genre de code est juste ignoble et devrait être catapulté en orbite à coup de bombes nucléaires (pour paraphraser Linus).
Sur un bout de code à la con, on voit bien que pour 2 lignes utiles qui devraient conduire à une complexité cyclomatique de 1 et dont le pseudo-code serait
fooBar() {
foo()
bar()
}
on en arrive à une 15aine de lignes de code et une complexité de 4.
Sur un soft d'une complexité standard, je te laisse imaginer ce que ça donne…
Idem en maintenance/évolution, alors que sur le pseudo-code on n'aurait qu'à ajouter une ligne entre foo() et bar(), en C on va devoir toucher aussi à toute la partie nettoyage/gestion d'erreur, aussi bien dans notre code que dans le code appelant. Idéal pour semer des régressions aux 4 coins de l'appli…
Au niveau développement, l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète) voire pire, carrément le code source…
Et même s'il prend la peine d'aller lire la doc, il ne sait généralement pas quoi faire en cas d'erreur, sinon se mettre à remonter à l'appelant toutes les erreurs de sa couche basse. « Eh les gars, on est en train de recoder les check-exceptions là ! »
Par extension, tout code en C DEVRAIT être codé selon ce principe, sauf à conduire aux différents problèmes soulevés PAR UN UTILISATEUR FINAL, c'est donc carrément le langage C qui devrait être mis en orbite !
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Aeris (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 1.
Ça ne change pas grand chose au final, ce genre de code est juste ignoble et devrait être catapulté en orbite à coup de bombes nucléaires (pour paraphraser Linus).
Sur un bout de code à la con, on voit bien que pour 2 lignes utiles qui devraient conduire à une complexité cyclomatique de 1 et dont le pseudo-code serait
on en arrive à une 15aine de lignes de code et une complexité de 4.
Sur un soft d'une complexité standard, je te laisse imaginer ce que ça donne…
Idem en maintenance/évolution, alors que sur le pseudo-code on n'aurait qu'à ajouter une ligne entre foo() et bar(), en C on va devoir toucher aussi à toute la partie nettoyage/gestion d'erreur, aussi bien dans notre code que dans le code appelant. Idéal pour semer des régressions aux 4 coins de l'appli…
Au niveau développement, l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète) voire pire, carrément le code source…
Et même s'il prend la peine d'aller lire la doc, il ne sait généralement pas quoi faire en cas d'erreur, sinon se mettre à remonter à l'appelant toutes les erreurs de sa couche basse.
« Eh les gars, on est en train de recoder les check-exceptions là ! »
Par extension, tout code en C DEVRAIT être codé selon ce principe, sauf à conduire aux différents problèmes soulevés PAR UN UTILISATEUR FINAL, c'est donc carrément le langage C qui devrait être mis en orbite !