Rendu final (anticipé et normal)

Chaque fichier Java que vous rendez doit obligatoirement contenir, dans les commentaires Javadoc, les noms et prénoms des auteurs ainsi que leur numéro SCIPER, placé entre parenthèses. La parenthèse ouvrante doit être immédiatement suivie des six chiffres du numéro SCIPER puis d'une parenthèse fermante. L'exemple ci-dessous illustre la manière correcte de formater ce numéro :

/**
 * @author Marie Dupond (123456)
 * @author Pierre Durand (654321)
 */

Les numéros SCIPER sont extraits automatiquement par notre système de gestion des rendus, qui refuse toute archive ne contenant pas entre un et deux numéros SCIPER différents, formatés comme décrit ci-dessus. Il est donc capital que vous respectiez cette règle.

Pour créer l'archive Zip contenant les fichiers de votre projet, procédez ainsi dans Eclipse :

1. Dans l'explorateur de paquetage (Package explorer), sélectionnez votre projet.
2. Dans le menu File, choisissez Export… et, dans la boîte de dialogue qui s'ouvre, déroulez la section General, sélectionnez Archive File puis cliquez sur le bouton Next.
3. Dans la boîte de dialogue qui suit, le nom de votre projet apparaît en haut à gauche avec une case cochée et un triangle permettant d'examiner son contenu. Cliquez sur ce triangle afin de pouvoir sélectionner plus précisément les données à exporter.
4. Une fois votre projet déroulé, vous devriez voir apparaître tous les répertoires de premier niveau qu'il contient, à savoir bin, data, src et test. Chacun de ces répertoires est accompagné d'une case à cocher qui détermine si son contenu est exporté ou non. Désélectionnez toutes les cases à cocher des répertoires sauf celles des répertoires src et test, puisque vous ne devez rendre que ces deux parties de votre projet (src contient les fichiers Java que vous avez écrits, test les tests). Votre boîte de dialogue devrait alors ressembler à celle de la figure 1 ci-dessous.
5. Choisissez l'endroit où créer l'archive (p.ex. le bureau de votre ordinateur) et son nom (p.ex. isochrone.zip) en cliquant sur le bouton Browse… puis en naviguant à l'endroit approprié.
6. Cliquez sur le bouton Finish afin de créer l'archive Zip à l'endroit que vous avez choisi à l'étape précédente.

Une fois l'archive créée, nous vous conseillons de vous assurer que son contenu est correct. Il existe des programmes permettant de consulter et/ou d'extraire le contenu d'archives Zip pour la plupart des systèmes d'exploitation, ce qui vous permet de vérifier que la vôtre contient bien les fichiers attendus.

Au minimum, vérifiez que la taille de l'archive est proche de 40 Ko. Une taille nettement supérieure indique probablement que vous avez inclus les données d'horaire, ce qu'il ne faut absolument pas faire.

Une fois l'archive créée, il faut nous la transmettre en l'envoyant par e-mail à l'adresse cs108-s2@listes.epfl.ch. L'heure de réception de cet e-mail détermine l'heure de votre rendu.

Les e-mails envoyés à l'adresse ci-dessus sont traités automatiquement toutes les 10 minutes environ. Vous devriez donc recevoir une réponse à votre message dans ces délais. En cas de problème, merci de nous contacter via le forum du cours.

Les rendus multiples sont acceptés, mais seul le dernier est pris en considération. Dès lors, pour éviter tout problème, nous vous recommandons fortement de rendre une première version fonctionnelle de votre code dès que possible et de la mettre éventuellement à jour par la suite, mais au plus tard à la date limite mentionnée plus haut.

Les premiers 10% des points sont basés sur le bon respect des différentes règles administratives données dans ce document et ceux des étapes précédentes.

Les 50% suivants des points sont basés sur une évaluation du comportement de votre programme. Pour ce faire nous vérifierons la bonne exécution du programme lors du lancement de la méthode main de la classe ch.epfl.isochrone.gui.IsochroneTL, ainsi que la ressemblance visuelle avec le programme de référence.

Les 40% suivants des points seront attribués après une lecture attentive du code. La première tranche de 30% est attribuée en fonction des éventuelles erreurs dans les fonctionnalités qui n'auraient pas été détectées par le test de l'interface graphique et les 10% restants portent sur la qualité du code. A cet effet, nous avons compilé une liste de ce que nous estimons être les bonnes pratiques à respecter pour coder en Java. Cette liste n'est pas exhaustive et est principalement basée sur le guide de bonnes pratiques proposé par Oracle :

• Le code est proprement indenté. Eclipse peut indenter un fichier automatiquement en sélectionnant la totalité de son contenu (menu Edit, entrée Select All) puis en le ré-indentant en sélectionnant l'entrée Correct Indentation du menu Source.
• Toutes les méthodes et classes sont commentées en utilisant la syntaxe de Javadoc. Vous pouvez choisir de le faire en français ou en anglais, mais n'utilisez qu'une langue dans tout votre projet.
• Les parties de code complexes sont commentées afin de fournir des informations supplémentaires.
• Les composants des classes et interfaces apparaissent toujours dans l'ordre suivant :
  1. Les variables statiques triées par visibilité (les variables publiques en premier, puis les protégées, ensuite les variables sans modificateur de visibilité et enfin les variables privées).
  2. Les variable d'instance, également triées par visibilité.
  3. Les méthodes, triées par fonctionnalité et non par visibilité (p.ex. une méthode privée peut-être entre deux méthodes publiques si elle est utilisée uniquement par la première).
• Toutes les classes, variables et méthodes sont correctement nommées en anglais et en camel case, c-à-d que les mots qui forment un nom sont collés les uns aux autres et, à l'exception éventuelle du premier, commencent tous par une majuscule.
• Les noms de classes et d'interfaces commencent par une majuscule, les noms de variables et de méthodes par une minuscule. Les constantes sont nommées en majuscules avec des tirets bas "_" entre les mots. Les noms doivent avoir un sens, mais pas forcément être longs. Par exemple il est communément accepté de nommer i un index ou x et y des coordonnées.
• Le code est concis, clair et évite la duplication inutile. L'utilisation de variables pour les expressions se répétant plusieurs fois est recommandée.
• Les exécution inutiles sont évitées. Attention toutefois, ce genre d'optimisation ne doit pas se faire au détriment des points ci-dessus.
• Les expressions booléenne sont utilisées de façon intelligente, par exemple en évitant des constructions comme :
  • if (e) return true; else return false;
    (à remplacer par return e;),
  • if (e) return false; else return true;
    (à remplacer par return !e;),
  • if (e == false) …
    (à remplacer par if (!e) …).