PROFDINFO.COM

Votre enseignant d'informatique en ligne

Comment avoir ses points en laboratoire

Nous prenons pour acquis que tout étudiant avisé apprécie obtenir un maximum de points pour son travail; c'est pourquoi nous avons créé ce document qui énumère de façon la plus précise possible, nos exigences pendant le cours de KAB.

Nom des fichiers et noms des classes

Commentaires

Où vont les commentaires dans les fichiers que vous créez? Que devez-vous y mettre? Voilà les réponses:

Le fameux #pragma once

#pragma once est une instruction au pré-compilateur qui permet de nous assurer qu'un fichier .h ne sera jamais inclus plus d'une fois lors d'une même compilation. C'est toujours possible qu'un fichier .h soit inclus dans un autre, puis qu'on inclue le premier et le deuxième (qui contient le premier) dans le main. Cette situation peut être problématique et causer d'étranges bogues à la compilation.

Pour éviter ça, on peut utiliser #IFNDEF, #DEFINE et #ENDIF pour définir une constante à la précompilation et déclarer la classe seulement si cette constante n'a pas été définie avant, ou on peut utiliser #pragma once, solution équivalente et élégante en une seule ligne.

Y a-t-il une différence entre les deux? Oui: #pragma once est spécifique au compilateur (et ne sera donc pas nécessairement supportée par tous), alors que #ifndef est universelle. Dans le cadre de ce cours, comme nous utilisons (normalement) tous le même compilateur, vous pourrez choisir la méthode qui vous plaît -- n'oubliez toutefois pas d'en utiliser une pour éviter des problèmes, même si votre projet est simple et que ça ne semble rien changer de le faire ou non!

L'utilisation de constantes

Il est toujours une exellente pratique d'utiliser des constantes plutôt que des nombres magiques qui surgissent soudainement dans le code sans plus d'explication. L'utilisation d'une constante clarifie le code (c'est toujours plus beau de faire une boucle qui va de Min à Max que de 3 à 49) et simplifie sa maintenance (c'est toujours plus facile de changer un nombre à un seul endroit qu'à douze, disséminés partout dans le code, dans plusieurs fichiers).

Tant que nous n'aurons pas vu une meilleure méthode, déclarez les constantes au début du .h concerné, mais avant la déclaration de la classe. Par exemple:

////////////////////////////////////////////////
// Compteur.h
// Etienne Forest
// 2017-02-02
// Déclaration de la classe CCompteur
////////////////////////////////////////////////

#pragma once

const int Min = 0;
const int Max = 1000000; // Un million

class CCompteur
{
// ...
};

Le respect des spécifications

Lorsque l'énoncé de l'exercice spécifie certaines choses, vous devez les respecter. C'est possible que vous ayez en tête une autre façon de faire ça, qui peut même vous sembler meilleure que la méthode demandée. Peu importe, vous devez respecter les spécifications. C'est d'autant plus vrai si on vous fournit un .h ou un main pour tester vos classes -- modifier un .h a de grandes conséquences puisqu'on modifie alors l'interface: on ne devrait pas prendre ça à la légère. Et le professeur pourrait vouloir utiliser son main pour tester vos classes -- si ça mène à des erreurs, c'est vous qui en serez responsable.

Si vous pensez à une fonctionnalité supplémentaire, qui ne demande pas qu'on modifie les spécifications données et qui pourrait simplement être ajoutée au programme, libre à vous de le faire (en vous assurant que ce qui est demandé fonctionne toujours comme il le devrait et que les autres règles et normes de programmation soient respectées). Ceci ne vous donnera normalement pas de points supplémentaires (à moins que ça soit spécifié dans l'énoncé), mais si ça vous amuse, allez-y.

Lorsqu'on vous demande de créer un main qui teste vos classes, sans plus d'explications, vous pouvez être aussi créatif ou aussi simpliste que vous le voulez, tant que votre main teste effectivement chaque fonctionnalité de chaque classe (incluant des cas d'erreurs) et que son interface demeure claire.

Si l'interface d'une classe est fournie, vous pouvez toujours ajouter des méthodes privées (donc inutilisables de l'extérieur) qui vous seront utiles. Un get et un set peuvent être privés aussi, ne l'oubliez pas!

Les méthodes const

Toutes les méthodes qui ne modifient pas les attributs d'une classe devraient être déclarées const. C'est automatiquement le cas de tous les accesseurs (get), mais ça s'appliquera aussi sans aucun doute à plusieurs autres méthodes. Tâchez de développer le réflexe, c'est une bonne pratique.

L'encapsulation

C'est le premier grand principe de la programmation orientée objet et vous devrez vous assurer de le respecter en tout temps. Ça signifie que l'interface doit être simple et claire, que les détails de l'implémentation doivent être cachés et que l'objet bien encapsulé doit s'assurer de conserver en tout temps sa cohérence interne. Donc:

Séparer la classe de l'interface homme-machine (IHM)

À moins qu'il en soit spécifié autrement dans l'énoncé d'un exercice, votre classe ne doit normalement pas dépendre d'une IHM précise. Puisque la programmation orientée objet vise la réutilisation des objets d'un projet à un autre, on voudrait bien qu'une classe ne soit pas limitée à n'être utilisée que dans un projet console.

Évitez donc de mettre des cin et des cout directement dans vos méthodes. Normalement, la classe n'en fera pas et c'est le main qui s'occupera de ça (et de relayer l'information de et à la classe via des valeurs de retour et des paramètres). Ainsi, on pourra éventuellement utiliser votre classe dans un projet Windows sans console et tout fonctionnera aussi bien.

Notez que certaines exceptions à cette règle seront parfois faites pour simplifier les projets -- elles vous seront alors spécifiées.

Montrez nous votre progression et prenez de l'avance

Lorsque vous avez terminé un exercice, si vous n'êtes pas certain d'avoir bien fait les choses, montrez-le à votre professeur. Vous serez alors certain d'avancer dans la bonne direction!

Les séances d'exercices sont séparées par des séances théoriques disponibles dans des capsules vidéo. Parfois, la capsule vidéo sera indispensable pour arriver à faire correctement les laboratoires qui la suivent, mais parfois non. Si vous terminez rapidement les exercices demandés, c'est une bonne idée d'essayer de faire les suivants. Le professeur vous avisera si vous n'avez pas les notions théoriques nécessaires pour y arriver afin que vous ne perdiez pas votre temps.

N'hésitez pas à poser des questions

Sans sombrer dans l'excès et demander au professeur de valider chaque pas que vous faites, ne vous gênez pas pour poser des questions afin d'être certain d'avoir bien compris ce que vous devez faire, ou si vous êtes bloqué sur un problème qui semble insoluble. Toutefois, le professeur s'attend à ce que vous ayez tenté de faire du débogage avant de l'appeler à chaque problème...

La correction

Tous les exercices de laboratoire comptent et sont à remettre au cours où ils sont donnés (voir le calendrier sur la page du cours) ou, au plus tard, au cours suivant. Il est possible que vous soyez obligé de terminer un exercice à la maison si vous n'avez pas eu le temps de le compléter en classe. Ne vous fiez pas sur le fait que les heures en laboratoire sont suffisantes; du travail à la maison, particulièrement dans la deuxième moitié de la session, est à prévoir.

Lorsque vous avez terminé un exercice, montrez-le à votre professeur pour avoir vos points. Si le professeur n'est pas satisfait, il vous indiquera ce qui ne fonctionne pas avec votre exercice et vous pourrez le corriger et le lui remontrer par la suite, sans pénalité. Toutefois, un exercice montré en retard ne sera pas accepté. C'est donc important d'être en classe à chaque cours afin de ne pas accumuler de retard et de pouvoir remettre vos exercices à mesure que vous les faites. Travailler en classe vous permet également d'obtenir l'aide du professeur si vous en avez besoin -- ces exercices sont surtout là pour vous permettre d'apprendre et le professeur est toujours disponible pour vous aider ou réexpliquer les notions que vous avez mal comprises.