Un compilateur n'a pas pour but de vérifier ton code,
S'il veut le transformer, il faut qu'il l'interprète, et pour ca il a intérêt à vérifier un ton code. Bref, c'est un premier rempart. Il ne remplace pas les autres outils de vérification, mais il est complémentaire, et a l'avantage d'être situé en amont de la chaîne (sur le poste du développeur). Bref c'est tout bénef, donc pourquoi s'en passer ?
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça
Blablabla. Les compilateurs sont pensés en binôme avec le langage, les possibilité de contrôle (qualité) statique du compilateur sont pris en compte dans la grammaire du langage. Évidemment avec un langage non conçu pour être vérifié statiquement/compilé comme Python...
t, surtout, cela n'a aucune valeur !
Ah bah oui, moi je connais des gens qui roulaient à 180km/h et qui se sont tués avec une ceinture de sécurité, c'est bien la preuve que la ceinture de sécurité n'a aucune valeur !
Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester.
public void foo()
{
//todo : implement this !
}
ca compile, et je peux tester autre chose.
Et pose aussi de sérieuses questions quand à la qualité du code produit avec cette méthode.
Mais c'est pas une méthode ! C'est pas un plus un gage de qualité ! C'est juste un outil qui permet d'éviter un certain nombre d'erreur, et qu'à ce titre il paraît idiot de chercher à s'en passer.
C'est comme les tests unitaires, les outils d'analyses statiques de code, toussa, ce sont des outils, qui offrent un certain nombre de vérification, et il est toujours mieux de les utiliser que de s'en passer.
Le bonus c'est que la plupart sont complémentaires.
Euh là, je ne pige pas : le temps de compilation n'est pas ridicule, justement. Sur un projet Java un peu conséquent, cela prend "longtemps".
C'est peanuts par rapport au nombre de vérification que fait le compilateur. Combien de milliers de tests unitaires en Python faudrait-il écrire pour effectuer toutes les vérifications que fait le compilateur Java ? et le temps d'exécution de ces tests ?
Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois
Bof, un serveur d'intégration fait tout ça très bien.
Quand tu veux débugues et que tu testes une modif par minute, chaque seconde de plus est un calvaire (et une perte de temps).
Sauf que toi t'as 100 fois plus de bugs à débogguer, pendant ce temps moi le compilateur il m'a prévenu 100 fois que ca servait à rien de lancer mon code et de chercher à comprendre, l'erreur elle est là, à la ligne 13, caractère 20, d'ailleusr il me suggère même quoi faire. Niveau perte de temps, je sais pas qui en perd le plus...
tu me proposes de rajouter une étape supplémentaire qui n'apporte rien avec pour justification "oui mais ça prend pas longtemps". Attend, dis moi que je rêve...
Forcement, si tu pars du principe que :
- faire l'analyse lexicale
- faire l'analyse syntaxique
- faire des vérifications sémantique : typage, initialisation des variables, etc.
- faire des vérifications de contrat d'interface, de versionning, etc.
tout ca ne sert à rien avant d'exécuter ton programme, effectivement tu dois rêver.
Je pense que je suis loin d'être le seul à faire cela et, en faisant cela, on admet que l'étape de compilation est inutile.
Ben non, ca prouve juste une chose : que le temps de compilation est suffisamment anecdotique pour que tu recompiles systématiquement avant d'exécuter :-p
Ce qui est hallucinant surtout, c'est que t'es pas capable de te rendre compte du boulot que fait le compilateur (associé à un langage avec une syntaxe stricte et un typage statique). Tu dis que le compilateur fait rien, mais dans ta technique (sans compilateur), qui fait tout le "rien" du compilateur ? et quand ?
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 6.
S'il veut le transformer, il faut qu'il l'interprète, et pour ca il a intérêt à vérifier un ton code. Bref, c'est un premier rempart. Il ne remplace pas les autres outils de vérification, mais il est complémentaire, et a l'avantage d'être situé en amont de la chaîne (sur le poste du développeur). Bref c'est tout bénef, donc pourquoi s'en passer ?
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça
Blablabla. Les compilateurs sont pensés en binôme avec le langage, les possibilité de contrôle (qualité) statique du compilateur sont pris en compte dans la grammaire du langage. Évidemment avec un langage non conçu pour être vérifié statiquement/compilé comme Python...
t, surtout, cela n'a aucune valeur !
Ah bah oui, moi je connais des gens qui roulaient à 180km/h et qui se sont tués avec une ceinture de sécurité, c'est bien la preuve que la ceinture de sécurité n'a aucune valeur !
Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester.
public void foo()
{
//todo : implement this !
}
ca compile, et je peux tester autre chose.
Et pose aussi de sérieuses questions quand à la qualité du code produit avec cette méthode.
Mais c'est pas une méthode ! C'est pas un plus un gage de qualité ! C'est juste un outil qui permet d'éviter un certain nombre d'erreur, et qu'à ce titre il paraît idiot de chercher à s'en passer.
C'est comme les tests unitaires, les outils d'analyses statiques de code, toussa, ce sont des outils, qui offrent un certain nombre de vérification, et il est toujours mieux de les utiliser que de s'en passer.
Le bonus c'est que la plupart sont complémentaires.
Euh là, je ne pige pas : le temps de compilation n'est pas ridicule, justement. Sur un projet Java un peu conséquent, cela prend "longtemps".
C'est peanuts par rapport au nombre de vérification que fait le compilateur. Combien de milliers de tests unitaires en Python faudrait-il écrire pour effectuer toutes les vérifications que fait le compilateur Java ? et le temps d'exécution de ces tests ?
Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois
Bof, un serveur d'intégration fait tout ça très bien.
Quand tu veux débugues et que tu testes une modif par minute, chaque seconde de plus est un calvaire (et une perte de temps).
Sauf que toi t'as 100 fois plus de bugs à débogguer, pendant ce temps moi le compilateur il m'a prévenu 100 fois que ca servait à rien de lancer mon code et de chercher à comprendre, l'erreur elle est là, à la ligne 13, caractère 20, d'ailleusr il me suggère même quoi faire. Niveau perte de temps, je sais pas qui en perd le plus...
tu me proposes de rajouter une étape supplémentaire qui n'apporte rien avec pour justification "oui mais ça prend pas longtemps". Attend, dis moi que je rêve...
Forcement, si tu pars du principe que :
- faire l'analyse lexicale
- faire l'analyse syntaxique
- faire des vérifications sémantique : typage, initialisation des variables, etc.
- faire des vérifications de contrat d'interface, de versionning, etc.
tout ca ne sert à rien avant d'exécuter ton programme, effectivement tu dois rêver.
Je pense que je suis loin d'être le seul à faire cela et, en faisant cela, on admet que l'étape de compilation est inutile.
Ben non, ca prouve juste une chose : que le temps de compilation est suffisamment anecdotique pour que tu recompiles systématiquement avant d'exécuter :-p
Ce qui est hallucinant surtout, c'est que t'es pas capable de te rendre compte du boulot que fait le compilateur (associé à un langage avec une syntaxe stricte et un typage statique). Tu dis que le compilateur fait rien, mais dans ta technique (sans compilateur), qui fait tout le "rien" du compilateur ? et quand ?