Le 21/06/2011 08:50, JKB a écrit :Qu'est-ce qu'il ne faut pas lire...
JKB
Ben excuse-moi, mais avec mes exemples de code C totalement sûrs bardés
de if dans tous les coins, la complexité moyenne de test est de 2^(nb
appel de fonctions) alors qu'en Java elle est de 0.
Ajouter une fonction supplémentaire en Java coûte donc 0 quelque soit la
taille du projet.
En C, le coût proportionnel à la taille du projet
(passer de 10 à 11 appels passe la complexité de 2^10 = 1024 à 2^11 > 2048, passer de 30 [qui est la limite généralement admise en taille max
de fonction] à 31 de 1e19 à 2e19…).
Le code en C devient donc de moins en moins maintenable au fur et à
mesure des évolutions…
Le 21/06/2011 08:50, JKB a écrit :
Qu'est-ce qu'il ne faut pas lire...
JKB
Ben excuse-moi, mais avec mes exemples de code C totalement sûrs bardés
de if dans tous les coins, la complexité moyenne de test est de 2^(nb
appel de fonctions) alors qu'en Java elle est de 0.
Ajouter une fonction supplémentaire en Java coûte donc 0 quelque soit la
taille du projet.
En C, le coût proportionnel à la taille du projet
(passer de 10 à 11 appels passe la complexité de 2^10 = 1024 à 2^11 > 2048, passer de 30 [qui est la limite généralement admise en taille max
de fonction] à 31 de 1e19 à 2e19…).
Le code en C devient donc de moins en moins maintenable au fur et à
mesure des évolutions…
Le 21/06/2011 08:50, JKB a écrit :Qu'est-ce qu'il ne faut pas lire...
JKB
Ben excuse-moi, mais avec mes exemples de code C totalement sûrs bardés
de if dans tous les coins, la complexité moyenne de test est de 2^(nb
appel de fonctions) alors qu'en Java elle est de 0.
Ajouter une fonction supplémentaire en Java coûte donc 0 quelque soit la
taille du projet.
En C, le coût proportionnel à la taille du projet
(passer de 10 à 11 appels passe la complexité de 2^10 = 1024 à 2^11 > 2048, passer de 30 [qui est la limite généralement admise en taille max
de fonction] à 31 de 1e19 à 2e19…).
Le code en C devient donc de moins en moins maintenable au fur et à
mesure des évolutions…
>> > Non, ce n'est pas la seule différence. Plus de choses à gérer =>
>> > plus d'erreurs. A moins que tu écrives des programmes sans jamais
>> > aucune erreur ?
>>
>> Alors explique-moi pourquoi les plus belles conneries qui
>> m'aient été données de voir, c'est justement dans des codes Java ?
>
> C'est une expérience considérée comme statistiquement objective ?
Avec quinze ans de pratique sur les deux, je pense que ça
commence à montrer une tendance.
Bah tu es tout seul et rien de vérifiable, même pas de comparaison
dans des conditions objectives, rien... Est-ce que tu prétends que la
réputation du C de produire des programmes illisible est totalement
usurpée ?
>> > Moins d'attention du développeur gaspillée, moins de pollution
>> > dans le code.
>>
>> Aucun rapport. Si tu ne fais pas attention, tu feras des
>> conneries quel que soit le langage.
>
> Tu ne fais *jamais* de conneries ?
Ai-je prétendu le contraire ?
Et comme personne n'est parfait, la quantité de conneries dépend de la
difficulté et du nombre de trucs à surveiller. Pourquoi il y a plein de
failles dans des logiciels écrits en C ?
Est-ce que les gens qui
écrivent Apache (par exemple) sont des grosses quiches ? Ou est-ce que
le fait qu'il y ait 255 trucs à se rappeler par ligne de code peut
intervenir ?
>> > La partie à comprendre en moins en java c'est les destructeurs
>> > (C++),
>>
>> Oui, et on voit les conneries des pointeurs qui ne sont
>> jamais déréférencés avec ce que ça implique, par exemple...
>
> On parle toujours de Java là ? Il y a très peu de choses à
> déréférencer, seulement quelques ressources particulières, comme
> déjà mentionné (gestion de cache par exemple ; même pour ça on peut
> utiliser des références faibles).
Lorsqu'il reste un pointeur quelque part qui pointe sur une
zone de la mémoire, cette zone n'est pas libérée. C'est un effet
pervers du GC, que tu le veuilles ou non. Et ce genre de bêtise est
très vite fait.
Pas plus qu'en C. En Java on ne le fait pas partout, on se concentre
sur les quelques ressources concernées, c'est tout. Et il y en a peu.
Le cas que tu cites est assez rare.
> Oui, les développeurs qui ont une formation plus large et/ou plus
> approfondie sont mieux formés et donc plus compétent (enfin en
> supposant qu'ils aient tout assimilé). Tu veux démontrer que les
> développeurs mieux formés sont meilleurs ? Youhou, quelle grande
> découverte. Sauf que toutes ces compétences ne sont pas forcément
> nécessaires. Dans "peu ou prou", il y a "peu" : les développeurs
> n'ont pas besoin de connaître autant de subtilité (ça ne veut pas
> dire rien, mais moins de choses), et surtout pas à s'en préoccuper,
> même s'il savent comment ça fonctionne.
Il y a deux niveaux. Celui où le dev sait que ça se passe
d'une certaine façon même s'il ne doit pas le gérer et celui où le
dev ne pipe mot à ce qu'il fait parce qu'il n'a pas conscience des
mécanismes. Mon expérience me dit que la plupart des devs
java qui n'ont fait que du java sont dans la deuxième catégorie. Et
figure-toi, ça me pose quelques problèmes quand je suis
obligé de passer derrière eux.
De fait il y a moins de choses à comprendre. Pour éviter les fuites de
mémoire il suffit en gros de savoir que ça marche presque tout seul,
les exceptions étant une poignée de ressources (dont il faut se
préoccuper de manière particulière dans d'autres langages aussi, comme
les fichiers ou le cache).Pour ta gouverne, la JVM de Sun outrepasse allègrement les
options de mémoire minimale et maximale. Ne me demande pas pourquoi,
mais c'est un fait. J'ai un processus qui est censé ne pas dépasser
plus d'un Go de mémoire, et il occupe présentement 6 Go de mémoire de
autant de swap (Solaris sparc avec une JVM 1.6 64 bits). La
aussi, la JVM (ou son GC) sait mieux que le dev ce qu'il faut
utiliser comme paramètres. En fait, j'ai de plus en plus l'impression
que Java, c'est le microsoft des langage. Il sait mieux qu'un dev ce
qui est bon pour lui.
S'il y a un gros bug dans la JVM de Solaris, tu le signales aux gens
compétents. Je n'ai jamais vu ce comportement.
Je t'ai aussi déjà expliqué que dans la vraie vie, le dev qui
est pressé et dont le compilateur râle colle un gestionnaire
ramasse-tout (c'est aussi vrai en C++) et au final, c'est
contre-productif.
Ben je t'ai déjà répondu que le développeur pressé fera aussi des
conneries en C, c'est pareil.
>> > Non, ce n'est pas la seule différence. Plus de choses à gérer =>
>> > plus d'erreurs. A moins que tu écrives des programmes sans jamais
>> > aucune erreur ?
>>
>> Alors explique-moi pourquoi les plus belles conneries qui
>> m'aient été données de voir, c'est justement dans des codes Java ?
>
> C'est une expérience considérée comme statistiquement objective ?
Avec quinze ans de pratique sur les deux, je pense que ça
commence à montrer une tendance.
Bah tu es tout seul et rien de vérifiable, même pas de comparaison
dans des conditions objectives, rien... Est-ce que tu prétends que la
réputation du C de produire des programmes illisible est totalement
usurpée ?
>> > Moins d'attention du développeur gaspillée, moins de pollution
>> > dans le code.
>>
>> Aucun rapport. Si tu ne fais pas attention, tu feras des
>> conneries quel que soit le langage.
>
> Tu ne fais *jamais* de conneries ?
Ai-je prétendu le contraire ?
Et comme personne n'est parfait, la quantité de conneries dépend de la
difficulté et du nombre de trucs à surveiller. Pourquoi il y a plein de
failles dans des logiciels écrits en C ?
Est-ce que les gens qui
écrivent Apache (par exemple) sont des grosses quiches ? Ou est-ce que
le fait qu'il y ait 255 trucs à se rappeler par ligne de code peut
intervenir ?
>> > La partie à comprendre en moins en java c'est les destructeurs
>> > (C++),
>>
>> Oui, et on voit les conneries des pointeurs qui ne sont
>> jamais déréférencés avec ce que ça implique, par exemple...
>
> On parle toujours de Java là ? Il y a très peu de choses à
> déréférencer, seulement quelques ressources particulières, comme
> déjà mentionné (gestion de cache par exemple ; même pour ça on peut
> utiliser des références faibles).
Lorsqu'il reste un pointeur quelque part qui pointe sur une
zone de la mémoire, cette zone n'est pas libérée. C'est un effet
pervers du GC, que tu le veuilles ou non. Et ce genre de bêtise est
très vite fait.
Pas plus qu'en C. En Java on ne le fait pas partout, on se concentre
sur les quelques ressources concernées, c'est tout. Et il y en a peu.
Le cas que tu cites est assez rare.
> Oui, les développeurs qui ont une formation plus large et/ou plus
> approfondie sont mieux formés et donc plus compétent (enfin en
> supposant qu'ils aient tout assimilé). Tu veux démontrer que les
> développeurs mieux formés sont meilleurs ? Youhou, quelle grande
> découverte. Sauf que toutes ces compétences ne sont pas forcément
> nécessaires. Dans "peu ou prou", il y a "peu" : les développeurs
> n'ont pas besoin de connaître autant de subtilité (ça ne veut pas
> dire rien, mais moins de choses), et surtout pas à s'en préoccuper,
> même s'il savent comment ça fonctionne.
Il y a deux niveaux. Celui où le dev sait que ça se passe
d'une certaine façon même s'il ne doit pas le gérer et celui où le
dev ne pipe mot à ce qu'il fait parce qu'il n'a pas conscience des
mécanismes. Mon expérience me dit que la plupart des devs
java qui n'ont fait que du java sont dans la deuxième catégorie. Et
figure-toi, ça me pose quelques problèmes quand je suis
obligé de passer derrière eux.
De fait il y a moins de choses à comprendre. Pour éviter les fuites de
mémoire il suffit en gros de savoir que ça marche presque tout seul,
les exceptions étant une poignée de ressources (dont il faut se
préoccuper de manière particulière dans d'autres langages aussi, comme
les fichiers ou le cache).
Pour ta gouverne, la JVM de Sun outrepasse allègrement les
options de mémoire minimale et maximale. Ne me demande pas pourquoi,
mais c'est un fait. J'ai un processus qui est censé ne pas dépasser
plus d'un Go de mémoire, et il occupe présentement 6 Go de mémoire de
autant de swap (Solaris sparc avec une JVM 1.6 64 bits). La
aussi, la JVM (ou son GC) sait mieux que le dev ce qu'il faut
utiliser comme paramètres. En fait, j'ai de plus en plus l'impression
que Java, c'est le microsoft des langage. Il sait mieux qu'un dev ce
qui est bon pour lui.
S'il y a un gros bug dans la JVM de Solaris, tu le signales aux gens
compétents. Je n'ai jamais vu ce comportement.
Je t'ai aussi déjà expliqué que dans la vraie vie, le dev qui
est pressé et dont le compilateur râle colle un gestionnaire
ramasse-tout (c'est aussi vrai en C++) et au final, c'est
contre-productif.
Ben je t'ai déjà répondu que le développeur pressé fera aussi des
conneries en C, c'est pareil.
>> > Non, ce n'est pas la seule différence. Plus de choses à gérer =>
>> > plus d'erreurs. A moins que tu écrives des programmes sans jamais
>> > aucune erreur ?
>>
>> Alors explique-moi pourquoi les plus belles conneries qui
>> m'aient été données de voir, c'est justement dans des codes Java ?
>
> C'est une expérience considérée comme statistiquement objective ?
Avec quinze ans de pratique sur les deux, je pense que ça
commence à montrer une tendance.
Bah tu es tout seul et rien de vérifiable, même pas de comparaison
dans des conditions objectives, rien... Est-ce que tu prétends que la
réputation du C de produire des programmes illisible est totalement
usurpée ?
>> > Moins d'attention du développeur gaspillée, moins de pollution
>> > dans le code.
>>
>> Aucun rapport. Si tu ne fais pas attention, tu feras des
>> conneries quel que soit le langage.
>
> Tu ne fais *jamais* de conneries ?
Ai-je prétendu le contraire ?
Et comme personne n'est parfait, la quantité de conneries dépend de la
difficulté et du nombre de trucs à surveiller. Pourquoi il y a plein de
failles dans des logiciels écrits en C ?
Est-ce que les gens qui
écrivent Apache (par exemple) sont des grosses quiches ? Ou est-ce que
le fait qu'il y ait 255 trucs à se rappeler par ligne de code peut
intervenir ?
>> > La partie à comprendre en moins en java c'est les destructeurs
>> > (C++),
>>
>> Oui, et on voit les conneries des pointeurs qui ne sont
>> jamais déréférencés avec ce que ça implique, par exemple...
>
> On parle toujours de Java là ? Il y a très peu de choses à
> déréférencer, seulement quelques ressources particulières, comme
> déjà mentionné (gestion de cache par exemple ; même pour ça on peut
> utiliser des références faibles).
Lorsqu'il reste un pointeur quelque part qui pointe sur une
zone de la mémoire, cette zone n'est pas libérée. C'est un effet
pervers du GC, que tu le veuilles ou non. Et ce genre de bêtise est
très vite fait.
Pas plus qu'en C. En Java on ne le fait pas partout, on se concentre
sur les quelques ressources concernées, c'est tout. Et il y en a peu.
Le cas que tu cites est assez rare.
> Oui, les développeurs qui ont une formation plus large et/ou plus
> approfondie sont mieux formés et donc plus compétent (enfin en
> supposant qu'ils aient tout assimilé). Tu veux démontrer que les
> développeurs mieux formés sont meilleurs ? Youhou, quelle grande
> découverte. Sauf que toutes ces compétences ne sont pas forcément
> nécessaires. Dans "peu ou prou", il y a "peu" : les développeurs
> n'ont pas besoin de connaître autant de subtilité (ça ne veut pas
> dire rien, mais moins de choses), et surtout pas à s'en préoccuper,
> même s'il savent comment ça fonctionne.
Il y a deux niveaux. Celui où le dev sait que ça se passe
d'une certaine façon même s'il ne doit pas le gérer et celui où le
dev ne pipe mot à ce qu'il fait parce qu'il n'a pas conscience des
mécanismes. Mon expérience me dit que la plupart des devs
java qui n'ont fait que du java sont dans la deuxième catégorie. Et
figure-toi, ça me pose quelques problèmes quand je suis
obligé de passer derrière eux.
De fait il y a moins de choses à comprendre. Pour éviter les fuites de
mémoire il suffit en gros de savoir que ça marche presque tout seul,
les exceptions étant une poignée de ressources (dont il faut se
préoccuper de manière particulière dans d'autres langages aussi, comme
les fichiers ou le cache).Pour ta gouverne, la JVM de Sun outrepasse allègrement les
options de mémoire minimale et maximale. Ne me demande pas pourquoi,
mais c'est un fait. J'ai un processus qui est censé ne pas dépasser
plus d'un Go de mémoire, et il occupe présentement 6 Go de mémoire de
autant de swap (Solaris sparc avec une JVM 1.6 64 bits). La
aussi, la JVM (ou son GC) sait mieux que le dev ce qu'il faut
utiliser comme paramètres. En fait, j'ai de plus en plus l'impression
que Java, c'est le microsoft des langage. Il sait mieux qu'un dev ce
qui est bon pour lui.
S'il y a un gros bug dans la JVM de Solaris, tu le signales aux gens
compétents. Je n'ai jamais vu ce comportement.
Je t'ai aussi déjà expliqué que dans la vraie vie, le dev qui
est pressé et dont le compilateur râle colle un gestionnaire
ramasse-tout (c'est aussi vrai en C++) et au final, c'est
contre-productif.
Ben je t'ai déjà répondu que le développeur pressé fera aussi des
conneries en C, c'est pareil.
Le 21/06/2011 20:34, Yliur a écrit :Je t'ai aussi déjà expliqué que dans la vraie vie, le dev qui
> est pressé et dont le compilateur râle colle un gestionnaire
> ramasse-tout (c'est aussi vrai en C++) et au final, c'est
> contre-productif.
Ben je t'ai déjà répondu que le développeur pressé fera aussi des
conneries en C, c'est pareil.
D'autant plus que le gestionnaire collé à l'arrache aura au moins un
gros bénéfice : il est fiable car ne peut pas planter.
Le développeur médiocre en Java ne pourra pas oublier un cas, le
compilateur s'occupant de le rappeler à l'autre le cas échéant.
Et même la solution la plus sale atteindra le but voulu : traiter tous
les cas et rendre le code fiable.
À l'inverse en C, un mauvais dev va justement tout faire de travers et
louper les ¾ des tests. Bilan : un soft instable et non fiable?
Le 21/06/2011 20:34, Yliur a écrit :
Je t'ai aussi déjà expliqué que dans la vraie vie, le dev qui
> est pressé et dont le compilateur râle colle un gestionnaire
> ramasse-tout (c'est aussi vrai en C++) et au final, c'est
> contre-productif.
Ben je t'ai déjà répondu que le développeur pressé fera aussi des
conneries en C, c'est pareil.
D'autant plus que le gestionnaire collé à l'arrache aura au moins un
gros bénéfice : il est fiable car ne peut pas planter.
Le développeur médiocre en Java ne pourra pas oublier un cas, le
compilateur s'occupant de le rappeler à l'autre le cas échéant.
Et même la solution la plus sale atteindra le but voulu : traiter tous
les cas et rendre le code fiable.
À l'inverse en C, un mauvais dev va justement tout faire de travers et
louper les ¾ des tests. Bilan : un soft instable et non fiable?
Le 21/06/2011 20:34, Yliur a écrit :Je t'ai aussi déjà expliqué que dans la vraie vie, le dev qui
> est pressé et dont le compilateur râle colle un gestionnaire
> ramasse-tout (c'est aussi vrai en C++) et au final, c'est
> contre-productif.
Ben je t'ai déjà répondu que le développeur pressé fera aussi des
conneries en C, c'est pareil.
D'autant plus que le gestionnaire collé à l'arrache aura au moins un
gros bénéfice : il est fiable car ne peut pas planter.
Le développeur médiocre en Java ne pourra pas oublier un cas, le
compilateur s'occupant de le rappeler à l'autre le cas échéant.
Et même la solution la plus sale atteindra le but voulu : traiter tous
les cas et rendre le code fiable.
À l'inverse en C, un mauvais dev va justement tout faire de travers et
louper les ¾ des tests. Bilan : un soft instable et non fiable?
Un mauvais codeur C, tu le repères en cinq minutes. Autre question ?
Un mauvais codeur C, tu le repères en cinq minutes. Autre question ?
Un mauvais codeur C, tu le repères en cinq minutes. Autre question ?
J'aurais pu écrire :
sub write_to_file
{
return system("echo $_[0] > $_[1]");
}
J'aurais pu écrire :
sub write_to_file
{
return system("echo $_[0] > $_[1]");
}
J'aurais pu écrire :
sub write_to_file
{
return system("echo $_[0] > $_[1]");
}
Le 21/06/2011 21:00, JKB a écrit :Un mauvais codeur C, tu le repères en cinq minutes. Autre question ?
Ah ? Et pourquoi ne le pourrait-on pas en Java aussi ?
Sans parler que les try-catch-all sont détectables, pas l'absence de
code, donc aucun moyen de détecter un oubli de code de retour en C⁺⁺.
Réactivité en Java : au prochain commit (merci la CI !) avec 100% de
chance de le voir
Réactivité en C : à la prochaine relecture de code, et encore aucune
garantie de détecter le problème…
Le 21/06/2011 21:00, JKB a écrit :
Un mauvais codeur C, tu le repères en cinq minutes. Autre question ?
Ah ? Et pourquoi ne le pourrait-on pas en Java aussi ?
Sans parler que les try-catch-all sont détectables, pas l'absence de
code, donc aucun moyen de détecter un oubli de code de retour en C⁺⁺.
Réactivité en Java : au prochain commit (merci la CI !) avec 100% de
chance de le voir
Réactivité en C : à la prochaine relecture de code, et encore aucune
garantie de détecter le problème…
Le 21/06/2011 21:00, JKB a écrit :Un mauvais codeur C, tu le repères en cinq minutes. Autre question ?
Ah ? Et pourquoi ne le pourrait-on pas en Java aussi ?
Sans parler que les try-catch-all sont détectables, pas l'absence de
code, donc aucun moyen de détecter un oubli de code de retour en C⁺⁺.
Réactivité en Java : au prochain commit (merci la CI !) avec 100% de
chance de le voir
Réactivité en C : à la prochaine relecture de code, et encore aucune
garantie de détecter le problème…
Et ? Tu coupes ce qui t'intéresse. C'est dommage, parce que si tu
peux détecter ton try-catch-all, tu n'as aucun moyen de détecter
comment va remonter ton exception. Enfin passons.
> Réactivité en Java : au prochain commit (merci la CI !) avec 100% de
> chance de le voir
> Réactivité en C : à la prochaine relecture de code, et encore aucune
> garantie de détecter le problème…
Rien compris à ta prose. Exprime-toi clairement.
Et ? Tu coupes ce qui t'intéresse. C'est dommage, parce que si tu
peux détecter ton try-catch-all, tu n'as aucun moyen de détecter
comment va remonter ton exception. Enfin passons.
> Réactivité en Java : au prochain commit (merci la CI !) avec 100% de
> chance de le voir
> Réactivité en C : à la prochaine relecture de code, et encore aucune
> garantie de détecter le problème…
Rien compris à ta prose. Exprime-toi clairement.
Et ? Tu coupes ce qui t'intéresse. C'est dommage, parce que si tu
peux détecter ton try-catch-all, tu n'as aucun moyen de détecter
comment va remonter ton exception. Enfin passons.
> Réactivité en Java : au prochain commit (merci la CI !) avec 100% de
> chance de le voir
> Réactivité en C : à la prochaine relecture de code, et encore aucune
> garantie de détecter le problème…
Rien compris à ta prose. Exprime-toi clairement.
Ben je t'ai déjà répondu que le développeur pressé fera aussi des
conneries en C, c'est pareil.
Ben je t'ai déjà répondu que le développeur pressé fera aussi des
conneries en C, c'est pareil.
Ben je t'ai déjà répondu que le développeur pressé fera aussi des
conneries en C, c'est pareil.
Le 21/06/2011 21:32, JKB a écrit :Et ? Tu coupes ce qui t'intéresse. C'est dommage, parce que si tu
peux détecter ton try-catch-all, tu n'as aucun moyen de détecter
comment va remonter ton exception. Enfin passons.
Beuh ?
Remonter une exception que j'ai catch-all ?
La plaque ................................................... JKB
Et sachant quelles exceptions sont potentielles sur chaque méthode, je
peux parfaitement remonter toute la pile d'appel sans problème !
> Réactivité en Java : au prochain commit (merci la CI !) avec 100% de
> chance de le voir
> Réactivité en C : à la prochaine relecture de code, et encore aucune
> garantie de détecter le problème…
Rien compris à ta prose. Exprime-toi clairement.
En Java, au prochain commit dans la gestion de conf, l'intégration
continue se déclenchera. Findbug détectera immédiatement le catch-all et
alertera le responsable du projet en plus du commiter.
Le catch-all sera donc détecté à 100% dans les prochaines minutes de la
connerie et sera corrigée avant d'avoir pu se propager ailleurs dans le
code.
La détection d'erreur en Java est donc :
– quasi-immédiate (fonction de la fréquence de commit scm)
— fiable (100% de détection)
— automatique (Jenkins + Maven + Findbugs)
— sans propagation de l'erreur
En C, comme les erreurs ne sont pas explicites :
— aucun moyen de savoir si le retour d'une fonction est un code d'erreur
ou une valeur de retour quelconque
— aucun moyen de savoir quels sont TOUS les codes de retour possibles
— aucun moyen de savoir si TOUTES les fonctions appelantes traitent TOUS
les cas d'erreur possibles de TOUTES les fonctions appelées
il est impossible de garantir si le code qu'on a sous les yeux est
correct ou non et s'il traite correctement les erreurs, et encore moins
de manière automatisée.
Même si tu faisais une revue de code juste après l'introduction de
l'erreur, tu n'as aucune certitude de la détecter lors de la revue.
Pire, la proba de détection est dépendante de la compétence du relecteur
et du temps qu'il va y consacrer.
Encore pire, il est rare de faire des revues de code toutes les 10min,
tout au plus 1× par semaine. L'erreur a donc de fortes chances de s'être
propagée dans le code.
En C, la détection sera donc :
— longue (fonction de la fréquence de la revue de code)
— non fiable (aucune certitude de détection de l'erreur)
— manuelle (difficile de détecter l'absence de quelque chose dont on a
pas connaissance)
— avec propagation de l'erreur potentielle
Le 21/06/2011 21:32, JKB a écrit :
Et ? Tu coupes ce qui t'intéresse. C'est dommage, parce que si tu
peux détecter ton try-catch-all, tu n'as aucun moyen de détecter
comment va remonter ton exception. Enfin passons.
Beuh ?
Remonter une exception que j'ai catch-all ?
La plaque ................................................... JKB
Et sachant quelles exceptions sont potentielles sur chaque méthode, je
peux parfaitement remonter toute la pile d'appel sans problème !
> Réactivité en Java : au prochain commit (merci la CI !) avec 100% de
> chance de le voir
> Réactivité en C : à la prochaine relecture de code, et encore aucune
> garantie de détecter le problème…
Rien compris à ta prose. Exprime-toi clairement.
En Java, au prochain commit dans la gestion de conf, l'intégration
continue se déclenchera. Findbug détectera immédiatement le catch-all et
alertera le responsable du projet en plus du commiter.
Le catch-all sera donc détecté à 100% dans les prochaines minutes de la
connerie et sera corrigée avant d'avoir pu se propager ailleurs dans le
code.
La détection d'erreur en Java est donc :
– quasi-immédiate (fonction de la fréquence de commit scm)
— fiable (100% de détection)
— automatique (Jenkins + Maven + Findbugs)
— sans propagation de l'erreur
En C, comme les erreurs ne sont pas explicites :
— aucun moyen de savoir si le retour d'une fonction est un code d'erreur
ou une valeur de retour quelconque
— aucun moyen de savoir quels sont TOUS les codes de retour possibles
— aucun moyen de savoir si TOUTES les fonctions appelantes traitent TOUS
les cas d'erreur possibles de TOUTES les fonctions appelées
il est impossible de garantir si le code qu'on a sous les yeux est
correct ou non et s'il traite correctement les erreurs, et encore moins
de manière automatisée.
Même si tu faisais une revue de code juste après l'introduction de
l'erreur, tu n'as aucune certitude de la détecter lors de la revue.
Pire, la proba de détection est dépendante de la compétence du relecteur
et du temps qu'il va y consacrer.
Encore pire, il est rare de faire des revues de code toutes les 10min,
tout au plus 1× par semaine. L'erreur a donc de fortes chances de s'être
propagée dans le code.
En C, la détection sera donc :
— longue (fonction de la fréquence de la revue de code)
— non fiable (aucune certitude de détection de l'erreur)
— manuelle (difficile de détecter l'absence de quelque chose dont on a
pas connaissance)
— avec propagation de l'erreur potentielle
Le 21/06/2011 21:32, JKB a écrit :Et ? Tu coupes ce qui t'intéresse. C'est dommage, parce que si tu
peux détecter ton try-catch-all, tu n'as aucun moyen de détecter
comment va remonter ton exception. Enfin passons.
Beuh ?
Remonter une exception que j'ai catch-all ?
La plaque ................................................... JKB
Et sachant quelles exceptions sont potentielles sur chaque méthode, je
peux parfaitement remonter toute la pile d'appel sans problème !
> Réactivité en Java : au prochain commit (merci la CI !) avec 100% de
> chance de le voir
> Réactivité en C : à la prochaine relecture de code, et encore aucune
> garantie de détecter le problème…
Rien compris à ta prose. Exprime-toi clairement.
En Java, au prochain commit dans la gestion de conf, l'intégration
continue se déclenchera. Findbug détectera immédiatement le catch-all et
alertera le responsable du projet en plus du commiter.
Le catch-all sera donc détecté à 100% dans les prochaines minutes de la
connerie et sera corrigée avant d'avoir pu se propager ailleurs dans le
code.
La détection d'erreur en Java est donc :
– quasi-immédiate (fonction de la fréquence de commit scm)
— fiable (100% de détection)
— automatique (Jenkins + Maven + Findbugs)
— sans propagation de l'erreur
En C, comme les erreurs ne sont pas explicites :
— aucun moyen de savoir si le retour d'une fonction est un code d'erreur
ou une valeur de retour quelconque
— aucun moyen de savoir quels sont TOUS les codes de retour possibles
— aucun moyen de savoir si TOUTES les fonctions appelantes traitent TOUS
les cas d'erreur possibles de TOUTES les fonctions appelées
il est impossible de garantir si le code qu'on a sous les yeux est
correct ou non et s'il traite correctement les erreurs, et encore moins
de manière automatisée.
Même si tu faisais une revue de code juste après l'introduction de
l'erreur, tu n'as aucune certitude de la détecter lors de la revue.
Pire, la proba de détection est dépendante de la compétence du relecteur
et du temps qu'il va y consacrer.
Encore pire, il est rare de faire des revues de code toutes les 10min,
tout au plus 1× par semaine. L'erreur a donc de fortes chances de s'être
propagée dans le code.
En C, la détection sera donc :
— longue (fonction de la fréquence de la revue de code)
— non fiable (aucune certitude de détection de l'erreur)
— manuelle (difficile de détecter l'absence de quelque chose dont on a
pas connaissance)
— avec propagation de l'erreur potentielle
Arrête de te faire plus bête que tu n'es. Si la fonct ion A
la B qui appelle une palanquée et demi de fonctions imb riquées et
qu'il y a une exception qui arrive là-dedans, tu sais q u'elle
remonte au catch-all tout en haut. Tu ne sais pas de fa çon simple
qui l'a déclanchée ni pourquoi.
Et je continue à dire que c'est aussi idiot. Parce que lorsque tu as
un catch-all, rien ne te permet de façon _simple_ d'ajo uter toutes
les détections d'erreur à tous les niveaux.
Tu sais que tu as un
bout de code écrit par un goret, pas comment le corrige r.
Oui, et ? Elle est détectée, pas corrigée ! La bonn e façon de faire,
et dans _tous_ les langages, Java compris, c'est de comme ncer par
écrire les bouts de traitement des erreurs et de ne pas déléguer ce
traitement quand on aura du temps pour l'écrire !
On se contre-fiche de la détection si on ne sait pas co mment
corriger facilement.
En C aussi figure-toi. On n'a pas attendu Java pour point er les
fonctions qui renvoyaient des valeurs non utilisées.
> sans propagation de l'erreur
Gnî ?
Tu peux déjà te débrouiller
pour que la valeur de retour soit récupérée. Si apr ès, l'utilisateur
ne la traite pas, le problème est strictement le même qu'en Java.
Pardon ? Ces valeurs de retour sont _normalisées_ et pa rfaitement
_connues_.
> aucun moyen de savoir si TOUTES les fonctions appelantes traitent T OUS
> les cas d'erreur possibles de TOUTES les fonctions appelées
> il est impossible de garantir si le code qu'on a sous les yeux est
> correct ou non et s'il traite correctement les erreurs, et encore moins
> de manière automatisée.
C'est parfaitement possible. C'est même l'hygiène de base du
développeur C et pour ma part, il y a longtemps que j'a i automatisé
la tâche.
Euh... Comment dire... Tu viens de prouver en une ligne q ue tu n'as
aucune idée de la façon dont on fait une revue de cod e ou des tests
de code.
Tester la remontée des erreurs en C est un truc qui se fait
à partir de macros.
Je ne vais pas passer deux heures à t'expliquer
comment, mais il est très simple de provoquer une erreu r en C et de
voir ce qui se passe.
Non. Avec quelques scripts générant des fichiers d'en -têtes, c'est même
automatique.
> manuelle (difficile de détecter l'absence de quelque chose dont o n a
> pas connaissance)
Pardon ?
Arrête de te faire plus bête que tu n'es. Si la fonct ion A
la B qui appelle une palanquée et demi de fonctions imb riquées et
qu'il y a une exception qui arrive là-dedans, tu sais q u'elle
remonte au catch-all tout en haut. Tu ne sais pas de fa çon simple
qui l'a déclanchée ni pourquoi.
Et je continue à dire que c'est aussi idiot. Parce que lorsque tu as
un catch-all, rien ne te permet de façon _simple_ d'ajo uter toutes
les détections d'erreur à tous les niveaux.
Tu sais que tu as un
bout de code écrit par un goret, pas comment le corrige r.
Oui, et ? Elle est détectée, pas corrigée ! La bonn e façon de faire,
et dans _tous_ les langages, Java compris, c'est de comme ncer par
écrire les bouts de traitement des erreurs et de ne pas déléguer ce
traitement quand on aura du temps pour l'écrire !
On se contre-fiche de la détection si on ne sait pas co mment
corriger facilement.
En C aussi figure-toi. On n'a pas attendu Java pour point er les
fonctions qui renvoyaient des valeurs non utilisées.
> sans propagation de l'erreur
Gnî ?
Tu peux déjà te débrouiller
pour que la valeur de retour soit récupérée. Si apr ès, l'utilisateur
ne la traite pas, le problème est strictement le même qu'en Java.
Pardon ? Ces valeurs de retour sont _normalisées_ et pa rfaitement
_connues_.
> aucun moyen de savoir si TOUTES les fonctions appelantes traitent T OUS
> les cas d'erreur possibles de TOUTES les fonctions appelées
> il est impossible de garantir si le code qu'on a sous les yeux est
> correct ou non et s'il traite correctement les erreurs, et encore moins
> de manière automatisée.
C'est parfaitement possible. C'est même l'hygiène de base du
développeur C et pour ma part, il y a longtemps que j'a i automatisé
la tâche.
Euh... Comment dire... Tu viens de prouver en une ligne q ue tu n'as
aucune idée de la façon dont on fait une revue de cod e ou des tests
de code.
Tester la remontée des erreurs en C est un truc qui se fait
à partir de macros.
Je ne vais pas passer deux heures à t'expliquer
comment, mais il est très simple de provoquer une erreu r en C et de
voir ce qui se passe.
Non. Avec quelques scripts générant des fichiers d'en -têtes, c'est même
automatique.
> manuelle (difficile de détecter l'absence de quelque chose dont o n a
> pas connaissance)
Pardon ?
Arrête de te faire plus bête que tu n'es. Si la fonct ion A
la B qui appelle une palanquée et demi de fonctions imb riquées et
qu'il y a une exception qui arrive là-dedans, tu sais q u'elle
remonte au catch-all tout en haut. Tu ne sais pas de fa çon simple
qui l'a déclanchée ni pourquoi.
Et je continue à dire que c'est aussi idiot. Parce que lorsque tu as
un catch-all, rien ne te permet de façon _simple_ d'ajo uter toutes
les détections d'erreur à tous les niveaux.
Tu sais que tu as un
bout de code écrit par un goret, pas comment le corrige r.
Oui, et ? Elle est détectée, pas corrigée ! La bonn e façon de faire,
et dans _tous_ les langages, Java compris, c'est de comme ncer par
écrire les bouts de traitement des erreurs et de ne pas déléguer ce
traitement quand on aura du temps pour l'écrire !
On se contre-fiche de la détection si on ne sait pas co mment
corriger facilement.
En C aussi figure-toi. On n'a pas attendu Java pour point er les
fonctions qui renvoyaient des valeurs non utilisées.
> sans propagation de l'erreur
Gnî ?
Tu peux déjà te débrouiller
pour que la valeur de retour soit récupérée. Si apr ès, l'utilisateur
ne la traite pas, le problème est strictement le même qu'en Java.
Pardon ? Ces valeurs de retour sont _normalisées_ et pa rfaitement
_connues_.
> aucun moyen de savoir si TOUTES les fonctions appelantes traitent T OUS
> les cas d'erreur possibles de TOUTES les fonctions appelées
> il est impossible de garantir si le code qu'on a sous les yeux est
> correct ou non et s'il traite correctement les erreurs, et encore moins
> de manière automatisée.
C'est parfaitement possible. C'est même l'hygiène de base du
développeur C et pour ma part, il y a longtemps que j'a i automatisé
la tâche.
Euh... Comment dire... Tu viens de prouver en une ligne q ue tu n'as
aucune idée de la façon dont on fait une revue de cod e ou des tests
de code.
Tester la remontée des erreurs en C est un truc qui se fait
à partir de macros.
Je ne vais pas passer deux heures à t'expliquer
comment, mais il est très simple de provoquer une erreu r en C et de
voir ce qui se passe.
Non. Avec quelques scripts générant des fichiers d'en -têtes, c'est même
automatique.
> manuelle (difficile de détecter l'absence de quelque chose dont o n a
> pas connaissance)
Pardon ?
