From 310d490320e096f14197e522852eb388b0cd7d0f Mon Sep 17 00:00:00 2001 From: Orestis <orestis@pop-os.localdomain> Date: Mon, 28 Nov 2022 23:17:20 +0100 Subject: [PATCH] added details --- slides/examen.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/slides/examen.md b/slides/examen.md index 88645c0..e2d49db 100644 --- a/slides/examen.md +++ b/slides/examen.md @@ -19,17 +19,18 @@ date: "2022-11-29" - Deux ou trois parties à chaque énoncé: - Une partie "théorique" qui décrit les structures de données et fonctionnalités. - Une partie "technique" qui propose un exemple d'exécution de votre programme avec entrées et sorties. - - Une partie "exemple" où vous pouvez tester l'exécution de votre programme. -- Il faut implémenter les trois pour avoir tous les points. + - Une partie "exemple" (pas obligatoire) où d'autres exemples sont donnés afin de tester l'exécution de votre programme. +- Votre code doit avoir **exactement** le comportement des exemples donnés **sous peine de sanctions**. +- Chaque code doit être **dans un unique fichier .c** (`ex1.c`, `ex2.c`, ...). # Évaluation (technique) - L'évaluation se base surtout sur des critères de fonctionnement: - - le code compile-t-il? - - s'exécute-t-il? + - le code compile-t-il? (on regarde même pas) + - s'exécute-t-il? (on regarde un peu) - le code demandé est-il réalisé? - donne-t-il des résultats corrects? -- Si vous laissez des warnings ou des erreurs de sanitizers vous aurez des malus. +- Si vous laissez des warnings ou des erreurs de sanitizers vous aserez pénalisé·e·s. # Évaluation (style) -- GitLab