README.md

subtitle: Code morse – Lecture de fichier et arbre binaire

Préambule

Pour ce travail pratique vous devez réaliser un programme qui traduit un message codé selon l’alphabet Morse. Votre programme devra :

• créer l’arbre du code Morse (de profondeur 4) à partir d’un fichier texte contenant pour chaque lettre de l’alphabet son équivalent en Morse (code-morse.txt). Chaque nœud correspond à une lettre, la branche de gauche se réfère aux points et la branche de droite aux traits ;
• afficher cet arbre par un parcours infixe ;
• lire une lettre en Morse et la traduire ;
• lire le fichier morse-decode.txt et le traduire. Le symbole / désigne une fin de mot ;
• encoder un fichier contenant un texte normal en un texte écrit en Morse.

Ce travail fera l’objet d’une évaluation, principalement sur sa forme.

Informations supplémentaires

Sur la figure \ref{fig:te}, vous trouverez le début de l’arbre qui contient les lettres T et E.

De plus les lettres de l’alphabet morse sont représentées dans la table ci-dessous.

A .-	J .---	S ...
B -...	K -.-	T -
C -.-.	L .-..	U ..-
D -..	M --	V ...-
E .	N -.	W .--
F ..-.	O ---	X -..-
G --.	P .--.	Y -.--
H ....	Q --.-	Z --..
I ..	R .-.	0 -----
1 .----	4 ....-	7 --...
2 ..---	5 .....	8 ---..
3 ...--	6 -....	9 ----.

Vous le trouverez également dans le fichier code-morse.txt.

Début de la construction de l’arbre Morse

Vous trouverez sur la figure \ref{fig:construct} le début de la construction de l’arbre Morse avec les nœuds contenant A et B.

Git

Quelques bonnes pratiques de la part de Gitlab.

Effectuer de petites modifications incrémentales

Écrire la plus petite quantité de code possible pour résoudre un problème. Après avoir identifié un problème ou une amélioration, la meilleure façon d’essayer quelque chose de nouveau et de non testé est de diviser la mise à jour en petits lots de valeur qui peuvent facilement et rapidement être testés avec l’utilisateurice final afin de prouver la validité de la solution proposée et de revenir en arrière au cas où cela ne fonctionnerait pas sans déprécier l’ensemble de la nouvelle fonctionnalité.

En effet, plus une branche est séparée de la branche principale ou de la ligne de code, plus les autres développeureuses sont en train de fusionner des modifications avec la branche principale, et des conflits d’intégration sont donc susceptibles de se produire lors de la fusion. Des commits fréquents et de petite taille résolvent ce problème. Les modifications incrémentales permettent également aux membres de l’équipe de revenir facilement en arrière en cas de conflit de fusion, en particulier lorsque ces modifications ont été correctement documentées sous la forme de messages de validation descriptifs.

Garder les commits atomiques

En rapport avec les petits changements, les commits atomiques sont une unité de travail unique, n’impliquant qu’une tâche ou une correction (par exemple, une mise à niveau, une correction de bogue, un remaniement). Les commits atomiques accélèrent les revues de code et facilitent les annulations, puisqu’ils peuvent être appliqués ou annulés sans effets secondaires imprévus.

L’objectif des commits atomiques n’est pas de créer des centaines de commits, mais de les regrouper en fonction du contexte. Par exemple, si un·e développeureuse a besoin de remanier le code et d’ajouter une nouvelle fonctionnalité, iel créera deux commits distincts plutôt que de créer un commit monolithique qui inclut des modifications ayant des objectifs différents.

Rédiger des messages de validation descriptifs

Les messages de validation descriptifs sont aussi importants que la modification elle-même. Rédigez des messages de livraison descriptifs commençant par un verbe au présent et à l’impératif afin d’indiquer l’objectif de chaque livraison de manière claire et concise. Chaque commit ne doit avoir qu’un seul objectif expliqué en détail dans le message de validation. La documentation de Git fournit des conseils sur la manière d’écrire des messages de validation descriptifs :

Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz," as if you are giving orders to the codebase to change its behavior. Try to make sure your explanation can be understood without external resources. Instead of giving a URL to a mailing list archive, summarize the relevant points of the discussion.

Rédiger les messages de validation de cette manière oblige les équipes logicielles à comprendre la valeur qu’un ajout ou une correction apporte à la ligne de code existante. Si les équipes estiment qu’il est impossible de trouver la valeur et de la décrire, il peut être utile de réévaluer les motivations qui sous-tendent le commit. Il sera toujours temps d’effectuer un commit plus tard, tant que les changements sont stockés et que les commits sont cohérents.

Évaluation

Pour ce TP, vous serez évalué·e·s selon les critères suivants :

• le programme est capable d’afficher dans le terminal le résultat du/de l’ :
  • décodage du message contenu dans le fichier morse-decode.txt,
  • encodage d’une chaine de caractères ;
• à la racine se trouve un fichier Makefile permettant de/d’ :
  • compiler le programme, uniquement si nécessaire,
  • exécuter le programme avec la cible run,
  • nettoyer le répertoire avec la cible clean ;
• le code est correctement versionné et rendu disponible¹ sur un dépot gitedu [coefficient 2] ;
• les fonctions sont :
  • correctement documentées,
  • regroupées dans un fichier morse.c (et son fichier d’en-tête morse.h évidemment) si elles ont un lien avec le code Morse,
  • clairement nommées.

La date limite de rendu est fixée au 21 janvier à 23h59. Le travail évalué sera celui disponible sur le dépôt gitedu à cet heure précise.

Un code qui ne compile pas ne sera pas évalué, impliquant la note 1.

Un conseil

Assurez-vous du bon fonctionnement du dépot git avant le 21 janvier à 23h58.

1. Pour me le partager, l’idéal est de passer par le menu manage→members de gitedu et m’inviter. ↩