Le problème c'est qu'ils n'apportent rien d'un point de vu du typage.
Quant a utiliser la non ergonomie d'un éditeur de texte pour dire que ça va continuer de compiler mais que ça va être buggé, je pourrais te dire la même chose de eclipse/intellij/visual qui interprètent mal quand je fait alt-& qui est censé m'envoyer sur un bureau et qui m'a rajouté un & là ou il ne fallait pas. (ou - avec alt-)
Je ne comprends pas du tout là où tu veux en venir. J'ai parlé de vim mais c'est un détail, j'ai aussi parlé de relecture de code. En philigrane tu aurais pu comprendre que je parle d'un cas réel de faille qu'il y a eu dans le noyau à cause d'un test qui était fais sur une affectation et pas sur comparaison. C'est ce qui me pousse à écrire mes conditions à l'envers en C et en C++ (la constante à gauche ou l'appel de méthode à gauche).
Pour moi, la différence entre connaître la syntaxe d'un langage et savoir s'en servir passe par l'utilisation de bonnes pratiques qui réduisent les risque d'erreur, qui vont faire en sorte d'empêcher ton code de compiler si tu l'utilise mal. C'est quelque chose qu'il faut prendre en compte évidement quand on écris une API (rendre le plus difficile possible les erreurs et le plus simple possible les bons comportements), mais aussi lorsque l'on écris simplement du code.
On a un exemple un peu plus bas d'une erreur de compréhension entre la version octale et la version par constante, je ne pense pas que celui qui l'a fait est plus mauvais qu'un autre, il est juste aller trop vite. Là il a retiré un droit ça ce serait vu vite, mais donner trop de droit aurait aussi était possible... L'important ce n'est pas d'aller vite, mais de faire bien. Entre les 2 écritures tu gagne ou tu perds quasiment pas de temps (ou alors commence par apprendre à te servir de ton éditeur/IDE), mais l'un ferra beugler le compilateur si tu passe certaines âneries.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par barmic . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 4.
Le problème c'est qu'ils n'apportent rien d'un point de vu du typage.
Je ne comprends pas du tout là où tu veux en venir. J'ai parlé de vim mais c'est un détail, j'ai aussi parlé de relecture de code. En philigrane tu aurais pu comprendre que je parle d'un cas réel de faille qu'il y a eu dans le noyau à cause d'un test qui était fais sur une affectation et pas sur comparaison. C'est ce qui me pousse à écrire mes conditions à l'envers en C et en C++ (la constante à gauche ou l'appel de méthode à gauche).
Pour moi, la différence entre connaître la syntaxe d'un langage et savoir s'en servir passe par l'utilisation de bonnes pratiques qui réduisent les risque d'erreur, qui vont faire en sorte d'empêcher ton code de compiler si tu l'utilise mal. C'est quelque chose qu'il faut prendre en compte évidement quand on écris une API (rendre le plus difficile possible les erreurs et le plus simple possible les bons comportements), mais aussi lorsque l'on écris simplement du code.
On a un exemple un peu plus bas d'une erreur de compréhension entre la version octale et la version par constante, je ne pense pas que celui qui l'a fait est plus mauvais qu'un autre, il est juste aller trop vite. Là il a retiré un droit ça ce serait vu vite, mais donner trop de droit aurait aussi était possible... L'important ce n'est pas d'aller vite, mais de faire bien. Entre les 2 écritures tu gagne ou tu perds quasiment pas de temps (ou alors commence par apprendre à te servir de ton éditeur/IDE), mais l'un ferra beugler le compilateur si tu passe certaines âneries.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)