Je pensais plus à la paranoïa du code où une valeur est testé 50 fois pour voir si elle est nulle ou pas. Combien de fois je tombe sur des truc en java qui ressemble à
if(machin.getBidule()!=null&&!machin.getBidule().isEmpty())// et encore c'est mieux que size() {Stringleopard=machin.getBidule().get(0);if(leopard!=null&&!leopard.isEmpty()){...}}
Et c'est fait quasiment systématiquement; si parfois je peux comprendre qu'on fasse la différence entre null et chaine vide, le plus souvent, dans le code où je suis ça n'a aucun sens. Ces tests alourdissent le code, et ont même tendance à planquer l'origine d'un problème; et encore c'est un truc trivial. Le hic c'est que le code est tellement foolproof, que lorsque les données d'entrée sont moisies on ne sait pas à quel endroit c'est mal branlé. Ça plante pas mais ça ne donne pas de résultats.
[^] # Re: Super workflow
Posté par fearan . En réponse au journal Un debugger est-il indispensable ?. Évalué à 3.
Je pensais plus à la paranoïa du code où une valeur est testé 50 fois pour voir si elle est nulle ou pas. Combien de fois je tombe sur des truc en java qui ressemble à
Et c'est fait quasiment systématiquement; si parfois je peux comprendre qu'on fasse la différence entre null et chaine vide, le plus souvent, dans le code où je suis ça n'a aucun sens. Ces tests alourdissent le code, et ont même tendance à planquer l'origine d'un problème; et encore c'est un truc trivial. Le hic c'est que le code est tellement foolproof, que lorsque les données d'entrée sont moisies on ne sait pas à quel endroit c'est mal branlé. Ça plante pas mais ça ne donne pas de résultats.
À noter que getBidule() est du genre
Il ne faut pas décorner les boeufs avant d'avoir semé le vent