Self-assessment quiz

# Qu’est-ce qu’une exception en programmation ? - [x] Un événement qui perturbe le flux normal d’un programme > ✅ Les exceptions sont des événements qui surviennent pendant l’exécution d’un programme et perturbent son flux normal. - [ ] Une erreur qui termine toujours le programme > ❌ Les exceptions ne terminent pas nécessairement un programme ; elles peuvent être interceptées et gérées. - [x] Une erreur qui peut être interceptée et gérée par le programme > ✅ Les programmes peuvent intercepter et gérer les exceptions pour éviter les plantages et maintenir une exécution fluide. - [ ] Un type de boucle en programmation > ❌ Les exceptions ne sont pas des boucles ; ce sont des mécanismes de gestion des erreurs pendant l’exécution. - [x] Un événement déclenché lorsqu’une donnée invalide ou un fichier manquant est rencontré > ✅ Les exceptions sont souvent déclenchées lorsqu’une donnée invalide est fournie ou qu’un fichier requis est manquant. # Quel est le but du bloc `try-except` ? - [x] Intercepter les exceptions qui peuvent survenir dans le bloc try > ✅ Le bloc `try-except` est utilisé pour intercepter et gérer les exceptions, empêchant le programme de planter. - [ ] Boucler à travers un bloc de code de manière répétée > ❌ Le bloc `try-except` n’est pas une boucle ; il sert à la gestion des erreurs. - [x] Gérer des types spécifiques d’exceptions > ✅ La clause `except` peut spécifier le type d’exception à gérer. - [ ] Terminer le programme lorsqu’une erreur survient > ❌ Le bloc `try-except` est conçu pour empêcher la terminaison du programme en gérant les exceptions. - [x] Fournir une manière propre de gérer les erreurs sans planter le programme > ✅ Le bloc `try-except` permet une gestion élégante des erreurs et la récupération du programme. # Que se passe-t-il si une exception survient et n’est pas interceptée par le programme ? - [x] Le programme se termine avec un message d’erreur > ✅ Si une exception n’est pas interceptée, le programme se termine et affiche un message d’erreur expliquant le problème. - [ ] L’exception est ignorée et le programme continue à s’exécuter > ❌ Les exceptions non gérées ne sont pas ignorées ; elles provoquent la terminaison du programme. - [ ] Le programme continue après avoir sauté l’exception > ❌ Une exception non gérée empêche le programme de continuer son exécution. - [ ] Le programme entre dans une boucle infinie > ❌ Les exceptions ne provoquent pas de boucles infinies ; elles causent la terminaison du programme sauf si elles sont gérées. - [x] Le type d’exception est affiché avec une trace d’appel (traceback) > ✅ Le type d’exception et une trace d’appel indiquant où l’erreur s’est produite sont affichés lorsqu’une exception n’est pas interceptée. # Quelle est la différence entre exceptions et assertions ? - [x] Les exceptions gèrent les erreurs pendant l’exécution, tandis que les assertions vérifient des conditions pendant le développement > ✅ Les exceptions servent à gérer les erreurs pendant l’exécution, tandis que les assertions sont des vérifications pour valider des conditions pendant le développement. - [ ] Les assertions servent à intercepter les erreurs de saisie utilisateur, tandis que les exceptions gèrent les erreurs logiques > ❌ Les assertions ne servent pas à intercepter les erreurs de saisie utilisateur ; elles sont utilisées pour vérifier des conditions pendant le développement. - [x] Les assertions sont utilisées pour s’assurer que certaines conditions sont vraies pendant l’exécution > ✅ Les assertions sont utilisées pour valider que certaines conditions sont vraies pendant l’exécution du programme. - [ ] Les exceptions sont utilisées uniquement pendant le développement > ❌ Les exceptions sont utilisées pendant l’exécution pour gérer les erreurs en production comme en développement. - [x] Les assertions peuvent être désactivées en environnement de production > ✅ Les assertions sont souvent désactivées en production pour éviter des vérifications inutiles et un surcoût en performance. # Quand doit-on utiliser les assertions dans son code ? - [x] Pour valider des hypothèses pendant le développement > ✅ Les assertions servent à valider des hypothèses dans le code, garantissant que les conditions attendues sont respectées pendant le développement. - [ ] Pour gérer les erreurs de saisie utilisateur > ❌ Les assertions ne doivent pas être utilisées pour gérer les erreurs de saisie utilisateur ; les exceptions sont plus appropriées pour cela. - [x] Pour vérifier des invariants et faire respecter des contraintes > ✅ Les assertions sont utiles pour vérifier des invariants et faire respecter des contraintes dans le code. - [ ] Pour remplacer toute gestion d’erreur en production > ❌ Les assertions sont généralement désactivées en production et ne doivent pas remplacer les mécanismes de gestion d’erreur comme les exceptions. - [x] Pour détecter tôt les erreurs logiques pendant la phase de développement > ✅ Les assertions aident à détecter les erreurs logiques pendant le développement en vérifiant les conditions attendues dans le code. # À quoi ne doivent PAS servir les assertions ? - [x] À gérer les erreurs de saisie utilisateur > ✅ Les assertions ne doivent pas être utilisées pour gérer les erreurs de saisie utilisateur. La validation des entrées est mieux gérée par les exceptions. - [ ] À vérifier que l’état du programme est correct > ❌ Les assertions sont destinées à vérifier l’état du programme pendant le développement. - [x] À vérifier des conditions pouvant être causées par des facteurs externes (ex. : saisie utilisateur) > ✅ Les assertions ne doivent pas être utilisées pour vérifier des conditions pouvant être affectées par des facteurs externes, comme la saisie utilisateur ou des problèmes réseau. - [ ] À vérifier des hypothèses pendant le développement > ❌ Les assertions sont conçues pour vérifier des hypothèses pendant le développement. - [x] À effectuer des tâches avec effets de bord, comme ouvrir des fichiers ou modifier des données > ✅ Les assertions ne doivent pas effectuer d’actions qui modifient l’état du programme ; elles servent uniquement à des vérifications, pas à des effets de bord.

# Qu’est-ce que la programmation défensive ? - [x] Une manière d’écrire du code qui anticipe les erreurs possibles des utilisateurs > ✅ La programmation défensive consiste à anticiper les erreurs des utilisateurs pour éviter les plantages et améliorer la gestion des erreurs. - [ ] Une méthode pour écrire du code qui s’exécute plus rapidement > ❌ La programmation défensive ne vise pas à optimiser la vitesse, mais à améliorer la résilience et la fiabilité. - [x] Une approche de programmation qui vise à réduire les plantages dus à de mauvaises entrées > ✅ En anticipant les erreurs et en validant les entrées, la programmation défensive aide à prévenir les plantages causés par de mauvaises données. - [ ] Une technique pour s’assurer que toutes les entrées utilisateur sont ignorées > ❌ La programmation défensive n’ignore pas les entrées ; elle s’assure qu’elles sont correctement validées. - [x] Une stratégie pour rendre les programmes plus résilients face aux conditions inattendues > ✅ La programmation défensive vise à rendre les programmes plus résilients en se préparant à des entrées ou conditions inattendues. # Quels sont les principes clés de la programmation défensive ? - [x] Validation des entrées > ✅ La validation des entrées garantit que les données sont correctement formatées et empêche que des données invalides ou malveillantes causent des problèmes. - [ ] Toujours supposer que l’utilisateur sait ce qu’il fait > ❌ La programmation défensive suppose que les utilisateurs peuvent faire des erreurs, donc elle valide les entrées au lieu de leur faire entièrement confiance. - [x] Valeurs par défaut sûres (fail-safe defaults) > ✅ Une valeur par défaut sûre garantit que lorsqu’un problème survient, le programme entre dans un état sûr plutôt que de poursuivre avec une action incorrecte ou dangereuse. - [x] Éviter les suppositions > ✅ La programmation défensive consiste à éviter les suppositions sur la validité des entrées ou des états du système, en se préparant aux erreurs. - [ ] Supposer que les erreurs ne se produiront jamais > ❌ C’est l’inverse en programmation défensive : on suppose que des erreurs se produiront et on s’y prépare. # Quel est le but de la validation des entrées en programmation défensive ? - [x] S’assurer que les entrées utilisateur sont valides avant de les traiter > ✅ La validation des entrées vérifie que les données sont bien formatées et sûres avant de les traiter, évitant ainsi des erreurs inattendues. - [ ] Permettre au programme de s’exécuter plus rapidement > ❌ La validation des entrées peut ajouter des étapes de traitement, mais son but est la sécurité, pas la vitesse. - [x] Empêcher que des entrées malveillantes ou malformées causent des erreurs > ✅ Une validation correcte des entrées aide à prévenir les vulnérabilités de sécurité et les plantages causés par des données invalides. - [ ] Supposer que toutes les entrées sont toujours correctes > ❌ La programmation défensive ne suppose pas que les entrées sont toujours correctes ; elle les valide pour garantir la sécurité. - [x] Améliorer la sécurité et la robustesse du programme > ✅ En validant les entrées, les programmes deviennent plus sûrs et robustes face aux attaques et erreurs utilisateur. # À quoi servent les assertions en programmation défensive ? - [x] Vérifier des conditions qui ne devraient jamais se produire en fonctionnement normal > ✅ Les assertions servent à vérifier des conditions qui ne devraient pas se produire en fonctionnement normal, permettant de détecter les bugs tôt pendant le développement. - [ ] Remplacer la validation des entrées > ❌ Les assertions ne remplacent pas la validation des entrées. Elles servent à vérifier les hypothèses faites pendant le développement. - [x] Aider à détecter les erreurs logiques pendant la phase de développement > ✅ Les assertions aident à détecter tôt les erreurs logiques en vérifiant que certaines conditions sont respectées pendant l’exécution. - [ ] Gérer toutes les erreurs utilisateur en production > ❌ Les assertions sont généralement désactivées en production et ne doivent pas être utilisées pour gérer les erreurs de saisie utilisateur. - [x] Faire respecter des conditions qui doivent toujours être vraies pour que le système fonctionne correctement > ✅ Les assertions font respecter des conditions qui doivent être vraies pour que le système fonctionne correctement, comme des invariants dans un programme. # Parmi les pratiques suivantes, lesquelles sont des exemples de programmation défensive ? - [x] Valider les entrées utilisateur > ✅ Valider les entrées garantit que les données fournies par l’utilisateur sont correctes et sûres à traiter. - [ ] Utiliser des variables globales pour partager des données dans le programme > ❌ L’utilisation de variables globales est déconseillée en programmation défensive car elle peut entraîner des bugs difficiles à détecter et des effets de bord non désirés. - [x] Fournir des messages d’erreur significatifs lorsque quelque chose ne va pas > ✅ Fournir des messages d’erreur clairs aide les utilisateurs à comprendre le problème et à ajuster leur comportement. - [x] Utiliser des valeurs par défaut sûres > ✅ Les valeurs par défaut sûres garantissent qu’en cas de problème, le système se comporte de manière sûre et prévisible. - [ ] Ignorer les cas limites pour simplifier le code > ❌ Ignorer les cas limites peut entraîner des bugs et un comportement imprévisible. La programmation défensive consiste à considérer les cas limites et à les gérer correctement.

# Quel est le but d’écrire des tests en développement logiciel ? - [x] Vérifier que le code se comporte comme attendu > ✅ Écrire des tests garantit que chaque partie du programme fonctionne comme prévu et respecte ses spécifications. - [ ] Faire en sorte que le code s’exécute plus rapidement > ❌ Les tests ne sont pas conçus pour améliorer la vitesse du code ; ils servent à vérifier sa correction. - [x] Détecter les bugs et régressions tôt dans le processus de développement > ✅ Les tests aident à détecter les bugs et régressions tôt, réduisant le coût de correction des erreurs plus tard dans le cycle de développement. - [x] S’assurer que les nouveaux changements ne cassent pas les fonctionnalités existantes > ✅ En exécutant les tests après des modifications du code, les développeurs peuvent confirmer que les nouvelles fonctionnalités ou corrections n’introduisent pas de nouveaux bugs ou ne cassent pas le code existant. - [ ] Corriger automatiquement les erreurs dans le code > ❌ Les tests aident à identifier les erreurs mais ne les corrigent pas automatiquement. # Quels sont les avantages des tests automatisés ? - [x] Ils facilitent la maintenance en détectant rapidement les problèmes > ✅ Les tests automatisés détectent rapidement les problèmes dans le code, facilitant la maintenance et la mise à jour du logiciel. - [ ] Ils remplacent le besoin d’une revue humaine du code > ❌ Les tests automatisés complètent la revue humaine, mais ne remplacent pas le besoin d’une revue approfondie par les développeurs. - [x] Ils supportent l’intégration et le déploiement continus (CI/CD) > ✅ Les tests automatisés sont essentiels dans les pipelines CI/CD, garantissant que les modifications de code sont bien testées avant d’être intégrées ou déployées. - [x] Ils renforcent la confiance des développeurs lors des modifications du code > ✅ Savoir que les tests détecteront les erreurs permet aux développeurs de refactoriser et d’améliorer le code en toute confiance. - [ ] Ils garantissent que le logiciel ne contiendra jamais de bugs > ❌ Les tests automatisés aident à réduire les bugs, mais ne peuvent garantir que tous les bugs seront détectés. # Que sont les tests unitaires ? - [x] Des tests qui se concentrent sur des unités ou composants individuels du logiciel > ✅ Les tests unitaires se concentrent sur le test d’unités individuelles, comme des fonctions ou méthodes, isolées du reste de l’application. - [ ] Des tests qui vérifient l’interaction entre plusieurs composants > ❌ Cela décrit les tests d’intégration, pas les tests unitaires. Les tests unitaires se concentrent sur des composants individuels. - [x] Des tests qui s’assurent qu’une seule fonction ou méthode fonctionne comme attendu > ✅ Les tests unitaires vérifient que des fonctions ou méthodes individuelles se comportent correctement. - [ ] Des tests qui vérifient la sécurité de l’ensemble de l’application > ❌ Les tests unitaires ne couvrent pas la sécurité ; c’est le rôle des tests de sécurité. - [x] Des tests écrits pour s’exécuter rapidement et indépendamment > ✅ Les tests unitaires sont conçus pour s’exécuter rapidement et indépendamment, garantissant que les composants individuels fonctionnent comme prévu. # Pourquoi est-il important d’écrire les tests avant le code (développement piloté par les tests) ? - [x] Les tests définissent le comportement attendu du code avant son implémentation > ✅ Écrire les tests en premier (comme dans le développement piloté par les tests) définit le comportement attendu du code avant son implémentation. - [ ] Cela garantit que le code ne contiendra pas de bugs > ❌ Écrire les tests en premier ne garantit pas l’absence de bugs, mais aide à les réduire en clarifiant les attentes. - [x] Cela encourage les développeurs à réfléchir de manière critique à la conception et aux fonctionnalités > ✅ Écrire les tests en premier encourage les développeurs à réfléchir à la conception et aux fonctionnalités du code avant de commencer l’implémentation. - [ ] Cela rend le code plus rapide à exécuter > ❌ Le développement piloté par les tests vise à améliorer la qualité du code, pas sa vitesse. - [x] Cela favorise la communication et assure une compréhension partagée des objectifs du projet > ✅ Écrire les tests avant le code favorise une meilleure communication et assure que toutes les parties prenantes partagent la même compréhension des objectifs du projet.

# Pourquoi est-il important de documenter le code ? - [x] Cela rend le code plus facile à lire et à maintenir > ✅ Documenter le code permet aux autres développeurs de comprendre et de maintenir facilement le code sans avoir à déchiffrer la logique par eux-mêmes. - [ ] Cela rend le code plus rapide à exécuter > ❌ La documentation améliore la lisibilité et la maintenabilité, pas la performance. - [x] Cela aide les nouveaux développeurs à monter en compétence rapidement > ✅ Un code bien documenté permet aux nouveaux développeurs de comprendre plus rapidement le but et la structure du projet, réduisant le temps d’intégration. - [x] Cela améliore la collaboration entre les membres de l’équipe > ✅ Une bonne documentation favorise la collaboration en fournissant une compréhension partagée de la base de code. - [ ] Cela élimine le besoin de commentaires dans le code > ❌ La documentation ne remplace pas les commentaires dans le code, qui expliquent la logique ou les décisions spécifiques. # Quel est le rôle des commentaires dans le code ? - [x] Rendre le code plus facile à comprendre > ✅ Les commentaires expliquent comment fonctionnent certaines parties du code, facilitant la compréhension d’une logique complexe ou non triviale. - [ ] Réécrire le code en anglais simple > ❌ Les commentaires ne doivent pas paraphraser le code lui-même ; ils doivent expliquer son but, sa logique et ses décisions de conception. - [x] Fournir des informations supplémentaires sur les algorithmes ou décisions > ✅ Les commentaires sont utiles pour décrire des algorithmes, des décisions de conception, des limitations ou des améliorations futures (TODO). - [x] Expliquer le but des parties complexes du code > ✅ Pour les sections non triviales du code, les commentaires sont essentiels pour expliquer le but et assurer la maintenabilité. - [ ] Éviter le besoin de documentation > ❌ Les commentaires complètent la documentation mais ne la remplacent pas. Les deux ont des objectifs différents dans le processus de développement. # Que ne doivent PAS faire les commentaires ? - [x] Paraphraser le code > ✅ Les commentaires ne doivent pas simplement reformuler le code en anglais simple ; ils doivent fournir des informations supplémentaires et des explications. - [ ] Expliquer les parties non triviales du code > ❌ Les commentaires doivent expliquer la logique non triviale ou complexe pour faciliter la compréhension. - [ ] Fournir un contexte pour les décisions de conception > ❌ Les commentaires peuvent être utilisés pour expliquer pourquoi certaines décisions de conception ont été prises. - [x] Surcharger le code avec des détails inutiles > ✅ Trop de commentaires peuvent rendre le code plus difficile à lire. Il est important de trouver un équilibre et de ne commenter que lorsque c’est nécessaire. - [x] Remplacer de bons noms de variables et fonctions > ✅ De bons noms de variables et fonctions devraient rendre le code auto-explicatif dans de nombreux cas, réduisant le besoin de commentaires excessifs. # Quel est l’objectif principal de documenter les signatures de fonctions et classes ? - [x] Décrire les paramètres d’entrée et les valeurs de retour > ✅ Documenter les signatures de fonctions et classes aide à expliquer les paramètres d’entrée, les valeurs de retour et les exceptions pouvant être levées. - [ ] Réécrire la logique de la fonction dans les commentaires > ❌ Le but n’est pas de réécrire la logique de la fonction mais de décrire ses entrées, sorties et comportement. - [x] Rendre le code plus facile à comprendre et à utiliser > ✅ Fournir une documentation claire des signatures de fonctions et classes facilite leur utilisation et compréhension par les développeurs. - [ ] Générer automatiquement des tests unitaires > ❌ Bien que les signatures aident aux tests, leur documentation n’a pas pour but de générer automatiquement des tests. - [x] Faciliter la génération de documentation externe > ✅ La documentation des signatures de fonctions et classes peut être utilisée pour générer une documentation externe que les développeurs peuvent consulter. # Comment les docstrings supportent-elles la documentation automatique ? - [x] Des outils comme `pydoc` peuvent extraire les docstrings pour générer la documentation > ✅ Les docstrings peuvent être extraites par des outils comme `pydoc` pour générer automatiquement une documentation lisible par l’humain. - [ ] Elles remplacent le besoin de commentaires dans le code > ❌ Les docstrings fournissent de la documentation mais ne remplacent pas les commentaires, qui expliquent des parties spécifiques du code ou de la logique. - [x] Elles fournissent des descriptions détaillées des fonctions, méthodes ou classes > ✅ Les docstrings décrivent le but et le comportement des fonctions, méthodes ou classes, qui peuvent ensuite être utilisées pour générer la documentation. - [x] Elles sont écrites directement dans le code source > ✅ Les docstrings sont intégrées directement dans le code source, ce qui les rend facilement accessibles aux développeurs et aux outils de documentation. - [ ] Elles sont utilisées uniquement dans les langages compilés > ❌ Les docstrings ne sont pas exclusives aux langages compilés ; elles sont largement utilisées dans les langages interprétés comme Python.