Le 18/06/2011 17:27, JKB a écrit :Un code est bon ou n'est pas bon. Il n'est pas notablement bon.
Au final le code sera toujours bon quelque soit le langage et la qualité
du code.
Le « notable » était juste là pour indiquer que toute modification
introduit potentiellement des effets de bord.
Le but d'un code propre n'étant pas de minimiser la fréquence de ces
effets de bord (ce qui est difficilement faisable) mais de rendre leur
correction rapide et fiable.D'autant que la gestion des erreurs par exception est une aberration
née dans le cerveau dément d'un analyste fou.
Certes, mal géré cela peut devenir dangereux.
C'est le pire des
systèmes lorsqu'on veut récupérer une erreur efficacement et de
façon propre. Le principe à la C d'une fonction qui renvoie un code
d'erreur est bien mieux pensé car plus simple et en testant les
retours des fonctions, on laisse toujours le programme dans un état
cohérent.
Si tu as un mauvais développeur en C, il va oublier de checker le code
de retour, qui au final ne sert à rien métier-ement parlant.
En Java, au mieux le code ne compilera pas (l'exception n'étant pas
gérée), au pire en cas d'erreur au runtime (RuntimeException), le code
s'arrêtera plutôt que de continuer dans un état totalement pourri.
Dans les 2 cas, le comportement final est plus fiable que celui du code
en C…
En C++ ou en Java, on peut rapidement avoir des surprises
amusantes.
Et en C encore plus.
Parce que même en testant le code de retour, 99% des développeurs ne
savent de toute façon pas comment gérer l'erreur, et encore moins
proprement.
Au moins en Java, le langage en lui-même met un 1er garde-fou en
remontant l'erreur tout le long de la pile jusqu'à ce qu'elle soit
traitée,
ou arrête le programme plutôt que de le laisser continuer dans
un état totalement incohérent si personne n'a daigné gérer cette erreur.
Le 18/06/2011 17:27, JKB a écrit :
Un code est bon ou n'est pas bon. Il n'est pas notablement bon.
Au final le code sera toujours bon quelque soit le langage et la qualité
du code.
Le « notable » était juste là pour indiquer que toute modification
introduit potentiellement des effets de bord.
Le but d'un code propre n'étant pas de minimiser la fréquence de ces
effets de bord (ce qui est difficilement faisable) mais de rendre leur
correction rapide et fiable.
D'autant que la gestion des erreurs par exception est une aberration
née dans le cerveau dément d'un analyste fou.
Certes, mal géré cela peut devenir dangereux.
C'est le pire des
systèmes lorsqu'on veut récupérer une erreur efficacement et de
façon propre. Le principe à la C d'une fonction qui renvoie un code
d'erreur est bien mieux pensé car plus simple et en testant les
retours des fonctions, on laisse toujours le programme dans un état
cohérent.
Si tu as un mauvais développeur en C, il va oublier de checker le code
de retour, qui au final ne sert à rien métier-ement parlant.
En Java, au mieux le code ne compilera pas (l'exception n'étant pas
gérée), au pire en cas d'erreur au runtime (RuntimeException), le code
s'arrêtera plutôt que de continuer dans un état totalement pourri.
Dans les 2 cas, le comportement final est plus fiable que celui du code
en C…
En C++ ou en Java, on peut rapidement avoir des surprises
amusantes.
Et en C encore plus.
Parce que même en testant le code de retour, 99% des développeurs ne
savent de toute façon pas comment gérer l'erreur, et encore moins
proprement.
Au moins en Java, le langage en lui-même met un 1er garde-fou en
remontant l'erreur tout le long de la pile jusqu'à ce qu'elle soit
traitée,
ou arrête le programme plutôt que de le laisser continuer dans
un état totalement incohérent si personne n'a daigné gérer cette erreur.
Le 18/06/2011 17:27, JKB a écrit :Un code est bon ou n'est pas bon. Il n'est pas notablement bon.
Au final le code sera toujours bon quelque soit le langage et la qualité
du code.
Le « notable » était juste là pour indiquer que toute modification
introduit potentiellement des effets de bord.
Le but d'un code propre n'étant pas de minimiser la fréquence de ces
effets de bord (ce qui est difficilement faisable) mais de rendre leur
correction rapide et fiable.D'autant que la gestion des erreurs par exception est une aberration
née dans le cerveau dément d'un analyste fou.
Certes, mal géré cela peut devenir dangereux.
C'est le pire des
systèmes lorsqu'on veut récupérer une erreur efficacement et de
façon propre. Le principe à la C d'une fonction qui renvoie un code
d'erreur est bien mieux pensé car plus simple et en testant les
retours des fonctions, on laisse toujours le programme dans un état
cohérent.
Si tu as un mauvais développeur en C, il va oublier de checker le code
de retour, qui au final ne sert à rien métier-ement parlant.
En Java, au mieux le code ne compilera pas (l'exception n'étant pas
gérée), au pire en cas d'erreur au runtime (RuntimeException), le code
s'arrêtera plutôt que de continuer dans un état totalement pourri.
Dans les 2 cas, le comportement final est plus fiable que celui du code
en C…
En C++ ou en Java, on peut rapidement avoir des surprises
amusantes.
Et en C encore plus.
Parce que même en testant le code de retour, 99% des développeurs ne
savent de toute façon pas comment gérer l'erreur, et encore moins
proprement.
Au moins en Java, le langage en lui-même met un 1er garde-fou en
remontant l'erreur tout le long de la pile jusqu'à ce qu'elle soit
traitée,
ou arrête le programme plutôt que de le laisser continuer dans
un état totalement incohérent si personne n'a daigné gérer cette erreur.
— La même convention de nommage de classes et surtout de namespace
En C++, on s'en fiche, seules comptent les interfaces et l'espace de
nommage. L'arborescence des sources n'a aucune siginification.
— Le même cycle de vie de développement
Ça n'a rien à faire ici. On peut avoir n'importe quel cycle de
développement dans n'importe quel langage.
— La même structure de site web
On parle de code source.
— La même gestion de dépendance
Ce n'est pas à une application de gérer des dépendances, mais au
système, sauf à vouloir absolument foutre le bordel, mais c'est
ainsi.
— La même manière d'intégrer leur travail dans ton propre travail
Hors sujet. Lorsque je parle d'intégrer un travail externe dans le
mien, je spécifie des interfaces. C'est indépendant du langage (et
java est justement très mauvais là-dedans).
— La même convention de nommage de classes et surtout de namespace
En C++, on s'en fiche, seules comptent les interfaces et l'espace de
nommage. L'arborescence des sources n'a aucune siginification.
— Le même cycle de vie de développement
Ça n'a rien à faire ici. On peut avoir n'importe quel cycle de
développement dans n'importe quel langage.
— La même structure de site web
On parle de code source.
— La même gestion de dépendance
Ce n'est pas à une application de gérer des dépendances, mais au
système, sauf à vouloir absolument foutre le bordel, mais c'est
ainsi.
— La même manière d'intégrer leur travail dans ton propre travail
Hors sujet. Lorsque je parle d'intégrer un travail externe dans le
mien, je spécifie des interfaces. C'est indépendant du langage (et
java est justement très mauvais là-dedans).
— La même convention de nommage de classes et surtout de namespace
En C++, on s'en fiche, seules comptent les interfaces et l'espace de
nommage. L'arborescence des sources n'a aucune siginification.
— Le même cycle de vie de développement
Ça n'a rien à faire ici. On peut avoir n'importe quel cycle de
développement dans n'importe quel langage.
— La même structure de site web
On parle de code source.
— La même gestion de dépendance
Ce n'est pas à une application de gérer des dépendances, mais au
système, sauf à vouloir absolument foutre le bordel, mais c'est
ainsi.
— La même manière d'intégrer leur travail dans ton propre travail
Hors sujet. Lorsque je parle d'intégrer un travail externe dans le
mien, je spécifie des interfaces. C'est indépendant du langage (et
java est justement très mauvais là-dedans).
C'est parfaitement débile puisque cela revient à gérer
une exception bien après l'erreur alors qu'il est beaucoup plus
simple de restaurer un état cohérent dans la fonction qui lève
l'erreur !
C'est parfaitement débile puisque cela revient à gérer
une exception bien après l'erreur alors qu'il est beaucoup plus
simple de restaurer un état cohérent dans la fonction qui lève
l'erreur !
C'est parfaitement débile puisque cela revient à gérer
une exception bien après l'erreur alors qu'il est beaucoup plus
simple de restaurer un état cohérent dans la fonction qui lève
l'erreur !
Le Sat, 18 Jun 2011 12:46:28 +0200,
Tonton Th écrivait :On 06/17/2011 11:56 PM, Aéris wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/06/2011 23:49, Tonton Th a écrit :Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
Les autotools n'ont rien à voir avec le langage. Et non, sur
un projet bien construit, les inclusions "croisées" de .h
ne posent pas de problèmes.
Le problème est d'avoir un projet _bien_ construit. Il y a longtemps
que je n'ai plus vu un petit jeune capable de construire
correctement un projet. Et les IDE pour cela ne sont pas une bonne
chose puisqu'elles masquent un tas de choses qui ne devraient pas
l'être.
JKB
Le Sat, 18 Jun 2011 12:46:28 +0200,
Tonton Th <tth@la.bas.invalid> écrivait :
On 06/17/2011 11:56 PM, Aéris wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/06/2011 23:49, Tonton Th a écrit :
Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?
Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
Les autotools n'ont rien à voir avec le langage. Et non, sur
un projet bien construit, les inclusions "croisées" de .h
ne posent pas de problèmes.
Le problème est d'avoir un projet _bien_ construit. Il y a longtemps
que je n'ai plus vu un petit jeune capable de construire
correctement un projet. Et les IDE pour cela ne sont pas une bonne
chose puisqu'elles masquent un tas de choses qui ne devraient pas
l'être.
JKB
Le Sat, 18 Jun 2011 12:46:28 +0200,
Tonton Th écrivait :On 06/17/2011 11:56 PM, Aéris wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/06/2011 23:49, Tonton Th a écrit :Le problème est le même en Java ou en C++.
Mêmes causes, mêmes conséquences.
Ajoute C ou ASM si tu le souhaites, cela ne change rien.
C'est même encore pire, avec des tricks comme les variables globales ou
que tout est accessible à la simple connaissance du .h…
En quoi l'utilisation raisonnable des variables globales
est-elle un "tricks" ?Et j'oublie aussi la croix et la bannière pour gérer proprement la
compilation sans passer par des abérations comme les autotools ou le
bordel sans nom des inclusions croisées de .h…
Les autotools n'ont rien à voir avec le langage. Et non, sur
un projet bien construit, les inclusions "croisées" de .h
ne posent pas de problèmes.
Le problème est d'avoir un projet _bien_ construit. Il y a longtemps
que je n'ai plus vu un petit jeune capable de construire
correctement un projet. Et les IDE pour cela ne sont pas une bonne
chose puisqu'elles masquent un tas de choses qui ne devraient pas
l'être.
JKB
Moi aussi je spécifie des interfaces.
Mais Maven spécifie aussi pour moi où et comment intégrer le .jar de la
dépendance dans mon projet, là où ton C se contentera de dire qu'il te
manque le .so…
C'est cool d'avoir un projet avec des interfaces, si tu n'es pas capable
de trouver comment installer le .so et ses dépendances ni comment
l'intégrer à la compilation, c'est d'une inutilité totale !
Moi aussi je spécifie des interfaces.
Mais Maven spécifie aussi pour moi où et comment intégrer le .jar de la
dépendance dans mon projet, là où ton C se contentera de dire qu'il te
manque le .so…
C'est cool d'avoir un projet avec des interfaces, si tu n'es pas capable
de trouver comment installer le .so et ses dépendances ni comment
l'intégrer à la compilation, c'est d'une inutilité totale !
Moi aussi je spécifie des interfaces.
Mais Maven spécifie aussi pour moi où et comment intégrer le .jar de la
dépendance dans mon projet, là où ton C se contentera de dire qu'il te
manque le .so…
C'est cool d'avoir un projet avec des interfaces, si tu n'es pas capable
de trouver comment installer le .so et ses dépendances ni comment
l'intégrer à la compilation, c'est d'une inutilité totale !
Parce que même en testant le code de retour, 99% des développeurs ne
> savent de toute façon pas comment gérer l'erreur, et encore moins
> proprement.
Tu te rends compte que tu rajoutes de l'eau à mon moulin ? Depuis
longtemps, je pense que Java est un truc permettant à des
programmeurs mauvais de pisser du code (jetable) et tu abondes dans
mon sens.
Parce que même en testant le code de retour, 99% des développeurs ne
> savent de toute façon pas comment gérer l'erreur, et encore moins
> proprement.
Tu te rends compte que tu rajoutes de l'eau à mon moulin ? Depuis
longtemps, je pense que Java est un truc permettant à des
programmeurs mauvais de pisser du code (jetable) et tu abondes dans
mon sens.
Parce que même en testant le code de retour, 99% des développeurs ne
> savent de toute façon pas comment gérer l'erreur, et encore moins
> proprement.
Tu te rends compte que tu rajoutes de l'eau à mon moulin ? Depuis
longtemps, je pense que Java est un truc permettant à des
programmeurs mauvais de pisser du code (jetable) et tu abondes dans
mon sens.
Le 18/06/2011 18:09, JKB a écrit :C'est parfaitement débile puisque cela revient à gérer
une exception bien après l'erreur alors qu'il est beaucoup plus
simple de restaurer un état cohérent dans la fonction qui lève
l'erreur !
Ah ?
malloc me retourne -1, je fais quoi ? Je ne sais même pas pourquoi il a
planté !
Sûrement à cause d'un manque de mémoire, ce qui ne sera pas récupérable
(de fortes chances de se taper -1 aussi sur un 2nd appel).
Le 18/06/2011 18:09, JKB a écrit :
C'est parfaitement débile puisque cela revient à gérer
une exception bien après l'erreur alors qu'il est beaucoup plus
simple de restaurer un état cohérent dans la fonction qui lève
l'erreur !
Ah ?
malloc me retourne -1, je fais quoi ? Je ne sais même pas pourquoi il a
planté !
Sûrement à cause d'un manque de mémoire, ce qui ne sera pas récupérable
(de fortes chances de se taper -1 aussi sur un 2nd appel).
Le 18/06/2011 18:09, JKB a écrit :C'est parfaitement débile puisque cela revient à gérer
une exception bien après l'erreur alors qu'il est beaucoup plus
simple de restaurer un état cohérent dans la fonction qui lève
l'erreur !
Ah ?
malloc me retourne -1, je fais quoi ? Je ne sais même pas pourquoi il a
planté !
Sûrement à cause d'un manque de mémoire, ce qui ne sera pas récupérable
(de fortes chances de se taper -1 aussi sur un 2nd appel).
Le 18/06/2011 18:09, JKB a écrit :Parce que même en testant le code de retour, 99% des développeurs ne
> savent de toute façon pas comment gérer l'erreur, et encore moins
> proprement.
Tu te rends compte que tu rajoutes de l'eau à mon moulin ? Depuis
longtemps, je pense que Java est un truc permettant à des
programmeurs mauvais de pisser du code (jetable) et tu abondes dans
mon sens.
Qu'on soit en C ou en Java, un mauvais développeur fera autant d'erreur.
Sauf qu'en C le résultat sera rapidement catastrophique, alors qu'en
Java pas mal de gardes-fous existent.
Et si on a à faire à un bon développeur, il prendra plus son pied avec
des bonnes pratiques très haut niveau type Maven, IoC ou n-tiers qu'à se
taper le coquillon avec du Makefile.
La question qui tue quand on doit intégrer un nouveau développeur : «
Patron, je monte comment ma nouvelle plate-forme pour attaquer le
développement ».
Réponse en Java : « mvn install »
Réponse en C/C⁺⁺ et tout le reste pratiquement : « euh… »
Et comme la réponse en Java sera toujours la même pour tous ses projets,
il finira par ne même plus poser la question !
Le 18/06/2011 18:09, JKB a écrit :
Parce que même en testant le code de retour, 99% des développeurs ne
> savent de toute façon pas comment gérer l'erreur, et encore moins
> proprement.
Tu te rends compte que tu rajoutes de l'eau à mon moulin ? Depuis
longtemps, je pense que Java est un truc permettant à des
programmeurs mauvais de pisser du code (jetable) et tu abondes dans
mon sens.
Qu'on soit en C ou en Java, un mauvais développeur fera autant d'erreur.
Sauf qu'en C le résultat sera rapidement catastrophique, alors qu'en
Java pas mal de gardes-fous existent.
Et si on a à faire à un bon développeur, il prendra plus son pied avec
des bonnes pratiques très haut niveau type Maven, IoC ou n-tiers qu'à se
taper le coquillon avec du Makefile.
La question qui tue quand on doit intégrer un nouveau développeur : «
Patron, je monte comment ma nouvelle plate-forme pour attaquer le
développement ».
Réponse en Java : « mvn install »
Réponse en C/C⁺⁺ et tout le reste pratiquement : « euh… »
Et comme la réponse en Java sera toujours la même pour tous ses projets,
il finira par ne même plus poser la question !
Le 18/06/2011 18:09, JKB a écrit :Parce que même en testant le code de retour, 99% des développeurs ne
> savent de toute façon pas comment gérer l'erreur, et encore moins
> proprement.
Tu te rends compte que tu rajoutes de l'eau à mon moulin ? Depuis
longtemps, je pense que Java est un truc permettant à des
programmeurs mauvais de pisser du code (jetable) et tu abondes dans
mon sens.
Qu'on soit en C ou en Java, un mauvais développeur fera autant d'erreur.
Sauf qu'en C le résultat sera rapidement catastrophique, alors qu'en
Java pas mal de gardes-fous existent.
Et si on a à faire à un bon développeur, il prendra plus son pied avec
des bonnes pratiques très haut niveau type Maven, IoC ou n-tiers qu'à se
taper le coquillon avec du Makefile.
La question qui tue quand on doit intégrer un nouveau développeur : «
Patron, je monte comment ma nouvelle plate-forme pour attaquer le
développement ».
Réponse en Java : « mvn install »
Réponse en C/C⁺⁺ et tout le reste pratiquement : « euh… »
Et comme la réponse en Java sera toujours la même pour tous ses projets,
il finira par ne même plus poser la question !
On est bien en train de parler de propreté de code, non ?
Si à chaque fois que je change de projet j'ai tout à réapprendre, ce
n'est ni efficace ni propre.
On est bien en train de parler de propreté de code, non ?
Si à chaque fois que je change de projet j'ai tout à réapprendre, ce
n'est ni efficace ni propre.
On est bien en train de parler de propreté de code, non ?
Si à chaque fois que je change de projet j'ai tout à réapprendre, ce
n'est ni efficace ni propre.
En Java, au mieux le code ne compilera pas
En Java, au mieux le code ne compilera pas
En Java, au mieux le code ne compilera pas
