Merci pour ton partage. Concernant ton paragraphe sur la clarté, j'émets des réserves et des désaccords.
la clarté: En lisant le texte d'un programme, il faut qu'il soit facile de comprendre l'intention des personnes qui l'ont écrit.
Je suis entièrement d'accord et j'irais même plus loin: un code source "beau" est plus facile à comprendre et vérifiable (relecture) que s'il suivait strictement les "règles" édictées par des normes, règles d'usages, etc.
"C'est véritablement utile puisque c'est joli." (Saint Exupéry - Le Petit Prince)
On dit qu'un programme a un bug (un défaut de fabrication) quand sa signification (pour l'ordinateur) ne correspond pas à l'intention de ses auteurs—une erreur a été faite pendant la transcription des idées dans le texte du programme.
Je pense que ta définition du bug est trop réductrice, incomplète et donc erronée. J'illustrerai ce point ci-dessous.
La clarté est un composant essentiel de la sûreté (éviter les comportements inattendus et dangereux).
C'est ton avis et celui-ci n'est pas objectif et ne correspond pas à la réalité de la production de code informatique: la clarté du langage est différente de la clarté du code produit.
Pour l'améliorer, 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.
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.
La réalité dans le monde des systèmes informatiques embarqués est tout autre: actuellement, je remarque que dans un bon nombre de cas, les bugs sont liés à des problèmes d'architectures, de "design", c'est à dire d'un malfonctionnement du cerveau du ou des personnes en charge de la cohérence d'un programme. Ensuite, des problèmes du non-respect du mode d'emploi des objets pilotés. Finalement assez peu de la transcription en elle-même: la faille WiFi WPA2 plaide en ma faveur!
1) Pour prendre 3 exemples:
- c'est l'histoire d'un architecte qui avait inversé le rôle de maître/esclave entre un producteur de données et d'un consommateur de données. Concrètement, celà donnait des trous et des désynchronisations de l'audio par rapport à la vidéo lors de l'affichage d'une vidéo (heureusement, la société a été rachetée, diluée, et avec ceci, la reconversion de ces personnes arrivés à leur niveau d'incompétence (principe de Peter): et oui, je suis frustré par ces personnes qui n'ont pas voulu écouter)
- ou encore plus proche, l'autoradio qui lit les AAC/MP3 dans ma voiture (Peugeot) interrompt la lecture avant la fin du fichier (et passe au fichier suivant) dès qu'il a envoyé la dernière trame au décodeur et pas dès que le dernier échantillon sonore a été réellement produit par le haut-parleur: en regardant le code, l'architecture, les tests, tu auras 100% de réussite aux vérifications et aucun bug trouvé! Pourtant mon vieux lecteur iPOD le fait correctement.
- Dans le domaine médical? Pourquoi le système de radiographie n'a-t-il pas pu démarrer le samedi quand je me suis présenté aux urgences et qu'il a fallu changer de service pour en trouver un qui accepte de démarrer? Je n'ai aucune preuve, mais je doute qu'il y ait un bug dans la transcription d'une idée
2) Le code est souvent écrit pour qu'il soit plus facilement vérifiable et contrôlé par des outils automatiques que pour la facilité de relecture: MISRA, SIL, PEP8 (ou autres règles rédigées par des personnes en manque de pouvoir). Ce qui donne du code illisible: i.e. immonde à relire et donc à vérifier la transcription. Finalement, la clarté du langage est dégradée par les normes et règles de production ce qui fait que beaucoup de code source passe les étapes de validation sans avoir été relu, compris et vérifié mais juste signé par un individu lambda. (pour le code d'Apple: qu'il n'ait pas été fait consciencieusement me surprendra moins que si on me dit qu'il n'y avait pas de relecture/peer review du code source!)
Mes conclusions sont:
- il y a, à notre époque, plus de problèmes dans le cerveau des concepteurs plutôt que dans la transcription des idées (dans le mien en premier!)
- La clarté du langage et du code source est régulièrement mise à mal par l'obligation de respecter des normes/règles de codage
- Les normes et règles de codage sont cependant indispensables pour réduire le nombre de bugs de transcription des idées au risque de dégrader la clarté.
D'où les questions: quels sont les liens entre la clarté d'un code source et celle du langage en lui-même? La clarté d'un code source peut-elle être forcée par le langage?
# Concernant la clarté
Posté par plr . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Merci pour ton partage. Concernant ton paragraphe sur la clarté, j'émets des réserves et des désaccords.
Je suis entièrement d'accord et j'irais même plus loin: un code source "beau" est plus facile à comprendre et vérifiable (relecture) que s'il suivait strictement les "règles" édictées par des normes, règles d'usages, etc.
"C'est véritablement utile puisque c'est joli." (Saint Exupéry - Le Petit Prince)
Je pense que ta définition du bug est trop réductrice, incomplète et donc erronée. J'illustrerai ce point ci-dessous.
C'est ton avis et celui-ci n'est pas objectif et ne correspond pas à la réalité de la production de code informatique: la clarté du langage est différente de la clarté du code produit.
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.
La réalité dans le monde des systèmes informatiques embarqués est tout autre: actuellement, je remarque que dans un bon nombre de cas, les bugs sont liés à des problèmes d'architectures, de "design", c'est à dire d'un malfonctionnement du cerveau du ou des personnes en charge de la cohérence d'un programme. Ensuite, des problèmes du non-respect du mode d'emploi des objets pilotés. Finalement assez peu de la transcription en elle-même: la faille WiFi WPA2 plaide en ma faveur!
1) Pour prendre 3 exemples:
- c'est l'histoire d'un architecte qui avait inversé le rôle de maître/esclave entre un producteur de données et d'un consommateur de données. Concrètement, celà donnait des trous et des désynchronisations de l'audio par rapport à la vidéo lors de l'affichage d'une vidéo (heureusement, la société a été rachetée, diluée, et avec ceci, la reconversion de ces personnes arrivés à leur niveau d'incompétence (principe de Peter): et oui, je suis frustré par ces personnes qui n'ont pas voulu écouter)
- ou encore plus proche, l'autoradio qui lit les AAC/MP3 dans ma voiture (Peugeot) interrompt la lecture avant la fin du fichier (et passe au fichier suivant) dès qu'il a envoyé la dernière trame au décodeur et pas dès que le dernier échantillon sonore a été réellement produit par le haut-parleur: en regardant le code, l'architecture, les tests, tu auras 100% de réussite aux vérifications et aucun bug trouvé! Pourtant mon vieux lecteur iPOD le fait correctement.
- Dans le domaine médical? Pourquoi le système de radiographie n'a-t-il pas pu démarrer le samedi quand je me suis présenté aux urgences et qu'il a fallu changer de service pour en trouver un qui accepte de démarrer? Je n'ai aucune preuve, mais je doute qu'il y ait un bug dans la transcription d'une idée
2) Le code est souvent écrit pour qu'il soit plus facilement vérifiable et contrôlé par des outils automatiques que pour la facilité de relecture: MISRA, SIL, PEP8 (ou autres règles rédigées par des personnes en manque de pouvoir). Ce qui donne du code illisible: i.e. immonde à relire et donc à vérifier la transcription. Finalement, la clarté du langage est dégradée par les normes et règles de production ce qui fait que beaucoup de code source passe les étapes de validation sans avoir été relu, compris et vérifié mais juste signé par un individu lambda. (pour le code d'Apple: qu'il n'ait pas été fait consciencieusement me surprendra moins que si on me dit qu'il n'y avait pas de relecture/peer review du code source!)
Mes conclusions sont:
- il y a, à notre époque, plus de problèmes dans le cerveau des concepteurs plutôt que dans la transcription des idées (dans le mien en premier!)
- La clarté du langage et du code source est régulièrement mise à mal par l'obligation de respecter des normes/règles de codage
- Les normes et règles de codage sont cependant indispensables pour réduire le nombre de bugs de transcription des idées au risque de dégrader la clarté.
D'où les questions: quels sont les liens entre la clarté d'un code source et celle du langage en lui-même? La clarté d'un code source peut-elle être forcée par le langage?