Je pense que ça dépend du contexte. Si tu travailles sur des petits projets (ou tu as la capacité d'avoir une vue globale) pas trop exigeants, avec des algos simples, pourquoi pas.
Je dis tjs qu'un typage fin c'est une paire de tests unitaires "gratuits". (sur Python, par ex, j'aurais tendance à mettre des tests unitaires là ou j'en aurais pas le besoin sur d'autres langages)
Et au contraire, le mieux est de s'assurer du bon type d'une variable le plus tôt possible...
Dans le cadre de la création pure, ça peut se tenir.
En revanche, dès que tu fais des modifs profondes : suppression de code, refactoring, changement de types, passage d'une lib à une autre etc.
C'est juste trop gros, pour que tu puisses juste t'appuyer uniquement sur ton IDE.
c'est à mon avis que tu as raté quelque chose à l'écriture.
90% des bugs c'est des ratés dans l'écriture.
Si on codait tous parfaitement du 1er coup, y'aurais jamais de débugage.
Et puis, plus il y a de legacy, d'autres devs et
En Python, il est excessivement rare que j'ai des erreurs de type (que ce soit dans des tests unitaires ou en prod), car j'essaie d'indiquer les types qui ne peuvent pas être directement inférés.
Python est un langage faiblement typé et qui a tendance justement à caster implicitement quand il peut (voir de faire du duck typing) donc foncièrement tu vas te retrouver avec moins d'erreurs de ce genre.
Enfin, ça c'est le sentiment. La réalité pour celui qui vient d'un langage fortement typé c'est que plein de choses sont nommé autrement (mais le soucis reste le même).
Si tu as supprimé un paramètre d'une fonction et que tu as oublié de l'enlever dans un appel, c'est un soucis de type pour moi car la signature de ta fonction a changé.
Par ex, en C# une fonction peut être passé dans une variable (un callback en somme) et du coup, la même fonction mais avec des signatures différentes seront des types distincts.
Tiens d'ailleurs : imagine que quelqu'un modifie la signature d'une fonction et push son travail.
Parallèlement à ça, je fais un appel avec l'ancienne signature : j'aurais pas de conflit au merge et y'aura un bug à l’exécution : pourtant j'ai été attentif et j'ai quand même un soucis.
Si t'as un bug lié à un oubli de try/catch c'est parce que tu n'as pas géré un "type" d'erreur.
Si tu fais un if/else sur un enum et que tu oublis un cas (ou plus fourbe, que t'as rajouté une entrée dans ton enum sans identifié minutieusement tous les endroits ou c'est appelé), tu te retrouves avec des cas non traités lié à un changement de type.
Bref, les exemples sont légion.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Je pense que ça dépend du contexte. Si tu travailles sur des petits projets (ou tu as la capacité d'avoir une vue globale) pas trop exigeants, avec des algos simples, pourquoi pas.
Je dis tjs qu'un typage fin c'est une paire de tests unitaires "gratuits". (sur Python, par ex, j'aurais tendance à mettre des tests unitaires là ou j'en aurais pas le besoin sur d'autres langages)
Dans le cadre de la création pure, ça peut se tenir.
En revanche, dès que tu fais des modifs profondes : suppression de code, refactoring, changement de types, passage d'une lib à une autre etc.
C'est juste trop gros, pour que tu puisses juste t'appuyer uniquement sur ton IDE.
90% des bugs c'est des ratés dans l'écriture.
Si on codait tous parfaitement du 1er coup, y'aurais jamais de débugage.
Et puis, plus il y a de legacy, d'autres devs et
Python est un langage faiblement typé et qui a tendance justement à caster implicitement quand il peut (voir de faire du duck typing) donc foncièrement tu vas te retrouver avec moins d'erreurs de ce genre.
Enfin, ça c'est le sentiment. La réalité pour celui qui vient d'un langage fortement typé c'est que plein de choses sont nommé autrement (mais le soucis reste le même).
Si tu as supprimé un paramètre d'une fonction et que tu as oublié de l'enlever dans un appel, c'est un soucis de type pour moi car la signature de ta fonction a changé.
Par ex, en C# une fonction peut être passé dans une variable (un callback en somme) et du coup, la même fonction mais avec des signatures différentes seront des types distincts.
Tiens d'ailleurs : imagine que quelqu'un modifie la signature d'une fonction et push son travail.
Parallèlement à ça, je fais un appel avec l'ancienne signature : j'aurais pas de conflit au merge et y'aura un bug à l’exécution : pourtant j'ai été attentif et j'ai quand même un soucis.
Si t'as un bug lié à un oubli de try/catch c'est parce que tu n'as pas géré un "type" d'erreur.
Si tu fais un if/else sur un enum et que tu oublis un cas (ou plus fourbe, que t'as rajouté une entrée dans ton enum sans identifié minutieusement tous les endroits ou c'est appelé), tu te retrouves avec des cas non traités lié à un changement de type.
Bref, les exemples sont légion.