:: Enseignements :: Licence :: L3 :: 2012-2013 ::

Charte des projets d'informatique

Contenu de cette charte

Ce document décrit toutes les règles à respecter pour rendre un projet. Sauf indication contraire explicite dans le sujet d'un projet, ces règles s'appliquent toujours par défaut à tous les projets. Tout manquement à ces règles est susceptible d'être sanctionné par une diminution de la note.

Règles à respecter

Compilation

Un projet doit obligatoirement au moins fonctionner sur les machines de l'université (dans les salles de TP de la formation), même s'il a été développé et testé sur d'autres systèmes.
Un projet doit compiler directement sans erreur.
Un projet doit comporter soit un script de compilation de type Makefile, script Ant build.xml ou autre, ou à défaut, un fichier d'information type readme.txt expliquant très précisément comment compiler le projet.

Rendu

Un projet doit être rendu au plus tard à la date précisée dans le sujet.
Un projet doit être rendu exclusivement sous la forme d'une archive zip ou tar.gz, à l'exclusion de tout autre format.
Le nom de l'archive rendue doit toujours être composé des logins des auteurs dans l'ordre alphabétique : login1-login2-login3.zip ou login1-login2-login3.tar.gz.
Quand on désarchive l'archive, elle doit créer un répertoire login1-login2-login3.
Les fichiers sources du projet doivent faire apparaître les noms et prénoms des auteurs dans un commentaire d'en-tête, ainsi que leurs logins.
Dans le cas d'un rendu par e-mail, on veillera à respecter les règles suivantes :
- le sujet du mail doit mentionner le nom de la formation, l'intitulé de la matière, les noms et auteurs, et le nom du projet s'il en a un (ex.: L3, projet C : Doc my code (Mickael Smith, John Doe)).
- le corps du mail doit mentionner les prénoms et noms complets des auteurs du projet, ainsi que leurs logins ;
- le mail doit être envoyé depuis un compte e-mail de l'Université, et non pas depuis une adresse du style poireau77@cyberpotager.com ;
- on n'oubliera pas d'attacher l'archive au mail ;
- >on teste pour vérifier ce que recevra l'enseignant en se mettant à sa place : on s'envoie l'archive par e-mail, on enregistre l'archive, on la désarchive, et on compile ce qu'elle contient ;
- >on n'enverra qu'un seul e-mail par projet à l'enseignant, et non pas : un sans l'archive, un avec une ancienne version, un avec un bug en moins, une version différente par membre du groupe, etc.

Rapport

Un projet doit systématiquement contenir un rapport écrit avec un vrai logiciel de traitement de texte (OpenOffice.org, Word, LaTeX, etc.).
Un rapport de projet doit être exclusivement au format PDF.
La première page d'un rapport de projet doit mentionner les prénoms et noms complets de tous les auteurs, le nom de la filière, l'intitulé de la matière, et le nom du projet le cas échéant.
Un rapport de projet doit permettre à quelqu'un d'utiliser le programme et de comprendre son fonctionnement. Il doit également justifier les choix qui ont été faits (structures de données, formats de fichier, etc.).
Un rapport de projet doit avoir été relu et ne pas être truffé de fautes.
Un rapport de projet ne doit pas contenir le listing de toutes les sources du projet.
Un rapport de projet ne doit pas faire une page.

Sources

Les sources des programmes doivent être suffisamment commentées pour que quelqu'un comprenant le langage de programmation utilisé puisse facilement comprendre et faire évoluer le programme. Les commentaires pourront éventuellement être demandés en anglais.
Les commentaires doivent être placés intelligemment. Il est inutile de commenter la syntaxe ("on fait une boucle", "on déclare une variable", etc.). En revanche, il faut donner, pour chaque fonction, une description de ce qu'elle fait, de ce qu'elle prend en paramètres (si ce n'est pas évident d'après le nom et le type des paramètres), et de ce qu'elle retourne.
Il faut détailler en commentaires les présupposés requis pour l'exécution d'une fonction. Par exemple, dans le cas d'une copie de tableau où le tableau de destination est passé en paramètre, il sera judicieux de préciser si ce tableau est censé être de dimension suffisante.
Il est très important de commenter le comportement de votre code dans les cas d'erreurs (ex.: que fait une fonction de suppression d'un élément dans une liste quand l'élément n'est pas dans la liste ?).
Il est nécessaire de commenter toute portion de code dont le sens n'est pas évident (*(a+4)+=SIZE&(++b<<(c%d))).
Les codes doivent être indentés proprement et suffisamment aérés.
La convention de nommage des identificateurs doit être cohérente dans tout le projet, même dans entre des portions de code écrites par des personnes différentes (choix entre identifier_name, IdentifierName, identifierName, Identifier_Name, identifier_Name, identifiername, etc.). Ces choix devront respecter les conventions du langage utilisé.
Les identificateurs doivent être nommés judicieusement de façon à faciliter la compréhension du programme : on évitera les choses du type void f(int entier,char* string,float reel).

Voici un exemple de code correct :

// Alloue et retourne un tableau de 'taille' entiers, ou NULL en cas d'erreur.
// Chaque case d'indice i du tableau est initialisée avec f(i), où f est une
//   fonction passée en argument de f_alloc.
int* f_alloc(int taille, int (*f)(int)) {
    int* tableau = (int*) malloc(taille * sizeof(int));
    if (tableau == NULL)
        return NULL;
    for (int i = 0; i < taille; i++)
        tableau[i] = f(i);
    return t;
}

Et voici un exemple à ne surtout pas suivre :

void func(int a[], int b) {
int i; // déclaration d'une variable i
for (i=0;i<b;i++) { printf("%d ",a[i]); } // on parcourt a en affichant chaque case
}

Divers

Un projet doit respecter scrupuleusement les indications données dans le sujet (format des entrées/sorties, syntaxe des paramètres, etc.).
On joindra des fichiers de test, avec les justifications du choix de ces tests (mise en évidence des cas testés).
Tous les membres d'un binôme/trinôme doivent avoir significativement participé au projet. Différents membres d'un même groupe peuvent avoir des notes différentes.