Tu as raison sur le fait que la définition des bugs comme des simples erreurs de transcription entre une idée (chez le programmeur) d'un comportement bas-niveau du programme et le code source correspondant est trop restrictive. Il y a aussi des comportements de programme que l'on considère comme des bugs parce qu'ils violent une spécification (là encore, que l'humain a en tête) de haut niveau, alors que le code source ait été pensé (et écrit) d'une façon qui ne la respecte pas. Il me faudrait essayer de reformuler.
Non, les outils de vérification/normes/règles de codage n'ont généralement pas comme objectif d'améliorer la clarté du langage.
Je pense que ton interprétation de ce que j'ai écrit est trop étroite. Pour rappel, j'avais mis :
certaines constructions des langages de programmation nous aident à exprimer notre intention, et les concepteurs et conceptrices de langages de programmation travaillent à concevoir des outils pour vérifier automatiquement que l'intention ainsi exprimée est cohérente avec le reste du texte du programme
Un aspect du langage qui entre dans ce cadre conceptuel est un système de typage. Finalement le fait de dire qu'une variable est un entier, ou une chaîne de caractère, ou bien un pointeur de fonction n'a pas tellement d'importance pour le comportement observable du programme à l'exécution (ça peut en avoir pour une compilation optimisée). Par contre ça en a beaucoup pour la clarté du programme (sans annotation de type, c'est plus dur de lire le code et de comprendre ce qu'il fait), et la redondance apportée par ces annotations permet à nos outils (les compilateurs) de dire parfois "attention, tu utilises la variable x comme un pointeur, mais tu l'as déclarée comme un entier, n'y a-t-il pas confusion ?", ce qui élimine des bugs.
(C'est intéressant de réfléchir au fait qu'un langage ou ses outils ne peuvent faire ça que s'il y a un peu de redondance entre les différentes choses qu'on dit sur notre programme (le code, les types, les assertions de debug/défense, mais aussi à la rigueur les les idiomes / figures de style (if (x = e) contre if ((x = e))), les commentaires, le sens des noms de variable...). Si on ne spécifiait tout qu'une seule fois, sans jamais aucun recouvrement, on ne pourrait pas détecter automatique d'incohérence.)
[^] # Re: Concernant la clarté
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Tu as raison sur le fait que la définition des bugs comme des simples erreurs de transcription entre une idée (chez le programmeur) d'un comportement bas-niveau du programme et le code source correspondant est trop restrictive. Il y a aussi des comportements de programme que l'on considère comme des bugs parce qu'ils violent une spécification (là encore, que l'humain a en tête) de haut niveau, alors que le code source ait été pensé (et écrit) d'une façon qui ne la respecte pas. Il me faudrait essayer de reformuler.
Je pense que ton interprétation de ce que j'ai écrit est trop étroite. Pour rappel, j'avais mis :
Un aspect du langage qui entre dans ce cadre conceptuel est un système de typage. Finalement le fait de dire qu'une variable est un entier, ou une chaîne de caractère, ou bien un pointeur de fonction n'a pas tellement d'importance pour le comportement observable du programme à l'exécution (ça peut en avoir pour une compilation optimisée). Par contre ça en a beaucoup pour la clarté du programme (sans annotation de type, c'est plus dur de lire le code et de comprendre ce qu'il fait), et la redondance apportée par ces annotations permet à nos outils (les compilateurs) de dire parfois "attention, tu utilises la variable
xcomme un pointeur, mais tu l'as déclarée comme un entier, n'y a-t-il pas confusion ?", ce qui élimine des bugs.(C'est intéressant de réfléchir au fait qu'un langage ou ses outils ne peuvent faire ça que s'il y a un peu de redondance entre les différentes choses qu'on dit sur notre programme (le code, les types, les assertions de debug/défense, mais aussi à la rigueur les les idiomes / figures de style (
if (x = e)contreif ((x = e))), les commentaires, le sens des noms de variable...). Si on ne spécifiait tout qu'une seule fois, sans jamais aucun recouvrement, on ne pourrait pas détecter automatique d'incohérence.)