Quiz du niveau 3 — Avancé : structurer son code

Quiz — Niveau 3 · Avancé : structurer son code

5 questions, une seule bonne réponse par question.
Répondez à tout, puis cliquez sur Corriger mes réponses : score et explications s'affichent.

1. Quel signal indique qu'il faut créer une PROCÉDURE ?

Quand le code dépasse trois lignes La DUPLICATION avant tout : dès que vous copiez-collez du code (ou vous apprêtez à le faire), il doit devenir une procédure — sinon chaque correction future devra être répétée partout, avec des oublis garantis. Aussi : la longueur et la complexité Uniquement en programmation objet Jamais, cela ralentit l'exécution

Portées : LOCALE (une fenêtre), GLOBALE (tout le projet), regroupées en COLLECTIONS par thème. Passez des PARAMÈTRES et renvoyez un RÉSULTAT plutôt que de dépendre de variables globales — celles-ci rendent le code imprévisible car modifiables de partout.

2. Quand utiliser un TABLEAU ASSOCIATIF plutôt qu'un tableau classique ?

Jamais, c'est plus lent Quand il faut RETROUVER une valeur par une CLÉ : l'accès est DIRECT, là où un tableau classique impose de parcourir les éléments un par un. Idéal pour les correspondances et les CACHES en mémoire Uniquement pour trier des nombres Pour afficher des images

Cas le plus rentable : charger une fois les données de référence dans un tableau associatif plutôt que d'interroger la base pour chaque ligne d'un import de cent mille enregistrements. ⚠️ Les CONVERSIONS de types (dates jour/mois, décimales virgule/point) restent une source majeure de bugs : contrôlez avant de convertir.

3. La POO est-elle obligatoire dans un projet WinDev de gestion ?

Oui, sans classes rien ne fonctionne NON : une application de gestion classique se développe très bien en PROCÉDURAL bien structuré. La POO devient utile pour les règles métier riches, l'encapsulation, les variantes d'un concept, les composants réutilisables et le travail en équipe Oui, imposée par le WLangage Non, le WLangage ne supporte pas les classes

Le WLangage supporte bien la POO (classes, membres, méthodes, constructeur, encapsulation, héritage, polymorphisme). Mais l'enjeu véritable est la SÉPARATION DES RESPONSABILITÉS, valable dans les deux paradigmes : un procédural propre vaut mieux qu'une POO mal comprise.

4. Quelle est la bonne méthode pour trouver l'origine d'un bug ?

Modifier le code au hasard jusqu'à ce que le symptôme disparaisse REPRODUIRE de façon fiable → ISOLER le périmètre (débogueur : point d'arrêt, pas à pas, inspection des variables) → COMPRENDRE la cause RÉELLE (pas le symptôme) → CORRIGER puis VÉRIFIER l'absence de régression Réinstaller WinDev Attendre que l'utilisateur s'y habitue

Un bug non reproductible ne peut pas être corrigé avec certitude. Attention aussi aux erreurs FONCTIONNELLES (le programme tourne mais le résultat est FAUX) : les plus dangereuses car rien ne les signale. Côté utilisateur : message COMPRÉHENSIBLE, jamais de code technique brut, et JOURNALISATION pour diagnostiquer à distance.

5. Quel est l'intérêt principal d'un COMPOSANT WinDev ?

Accélérer la compilation EMPAQUETER un ensemble d'éléments (fenêtres, procédures, classes, états) pour le réutiliser dans D'AUTRES PROJETS, avec une correction CENTRALISÉE : on corrige une fois et toutes les applications en bénéficient Réduire la taille de l'exécutable Traduire l'application

Une simple COLLECTION DE PROCÉDURES suffit pour organiser un même projet. Le composant se justifie pour un partage entre projets — au prix d'une vraie ingénierie : interface CLAIRE et STABLE, documentation, versions, tests. Complétez par les MODÈLES de fenêtres et les FENÊTRES INTERNES.

Passer au niveau 4Retour au sommaire du guide