geoffrey/s1-tp
geoffrey/s1-tp
Archived
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

[Echecs] Ajout LICENCE et modification README

Browse source 
Commit final avant rendu (faut bien s'arrêter un jour)
This commit is contained in:
Geoffrey Frogeye 2014-12-14 23:45:33 +01:00
parent 6ff94b2079
commit 6d44f9251a
2 changed files with 36 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
S1/Echecs/LICENCE Normal file
View file

@ -0,0 +1,21 @@
The MIT License (MIT)
Copyright (c) [year] [fullname]
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

20
S1/Echecs/README.md
View file

@ -13,13 +13,13 @@ Dans le dossier racine du projet :
python app.py python app.py
``` ```
(en supposant que `python` est dans la variable d'environnement `path` (ou `$PATH` sous Windows) et point vers l'éxecutable de Python 3) (en supposant que `python` est dans la variable d'environnement `path` (ou `$PATH` sous Windows) et point vers l’exécutable de Python 3)
##Objectifs non-réalisés ##Objectifs non-réalisés
###Objectifs de TP ###Objectifs de TP
* Implémenter le jeu d'échecs entier * Implémenter le jeu d'échecs
Le jeu d'échec n'est pas totalement implémenté, voici la liste non-exhaustive des règles qui ne sont pas implémentées Le jeu d'échec n'est pas totalement implémenté, voici la liste non-exhaustive des règles qui ne sont pas implémentées
@ -28,9 +28,13 @@ Le jeu d'échec n'est pas totalement implémenté, voici la liste non-exhaustive
* Prise en passant * Prise en passant
* Détection du "pat" (le joueur ne pouvant pas jouer est considéré comme perdant, même s'il n'est pas en échec) * Détection du "pat" (le joueur ne pouvant pas jouer est considéré comme perdant, même s'il n'est pas en échec)
* Pouvoir choisir entre jeu de dame et jeu d'échecs * Implémenter le jeu de dames
Le jeu de dame n'est pas implémenté, bien qu'il ne soit nécessaire de ne modifier aucune partie du code déjà existant. Le jeu de dames est tout à fait jouable, bien que certaines règles ne soient pas implémentés. En voici la liste non-exhaustive.
* L'enlèvement des pièces d'une rafle lors de la fin de celle-ci
* Partie nulle
* "Souffler n'est pas jouer" implémenté bien qu'abandonné en 1927 à des fins de démonstration
* Redimensionnement de la fenêtre * Redimensionnement de la fenêtre
@ -38,13 +42,17 @@ Il suffirait d'appeler `PlateauTk.redimCan(min(xMax, yMax))` à chaque redimensi
* Documenter et tester les fonctions * Documenter et tester les fonctions
Chaque fonction possède une brève description de son fonctionnemenent. L'ajout des types des arguments serait inutile, étant la majorité du temps des int. Le contenu des arguments s'expliquent par leur nom, à défaut par la description de la fonction. De plus, la majorité des fonctions dépendant de l'instance de leur classe, aucune doctest n'a été écrite, car cela aurait nécessité trop de code pour de simples fonctions. Chaque fonction possède une brève description de son fonctionnement. L'ajout des types des arguments serait inutile, étant la majorité du temps des int. Le contenu des arguments s'expliquent par leur nom, à défaut par la description de la fonction. De plus, la majorité des fonctions dépendant de l'instance de leur classe, aucune doctest n'a été écrite, car cela aurait nécessité trop de code pour de simples fonctions.
###Objectifs personnels ###Objectifs personnels
* Qualité du code * Qualité du code
Bien que le code fonctionne, soit plutôt flexible, relativement documenté et utilise la notion d'objet, il est loin d'être irréprochable. Certaines fonctions font probablement plus de calcul que nécessaire, la création de certaines variables pourraient être évité. L'ajout de plus de constante au lieu de valeurs arbitraire contribuerait à la lisibilité du code. Certaines instructions ne sont probablement pas sémantiquement correcte. Certaines parties du code devraient avoir une gestion d'erreurs car elles sont succeptibles d'en avoir. Bien que le code fonctionne, soit plutôt flexible, relativement documenté et utilise la notion d'objet, il est loin d'être irréprochable. Certaines fonctions font probablement plus de calcul que nécessaire, la création de certaines variables pourraient être évité. L'ajout de plus de constante au lieu de valeurs arbitraire contribuerait à la lisibilité du code. Certaines instructions ne sont probablement pas sémantiquement correcte. Certaines parties du code devraient avoir une gestion d'erreurs car elles sont susceptibles d'en avoir.
* Test
N'étant pas un joueur d'Échecs ni de Dames experimenté, je n'ai pas pu tester toutes les possibilités du jeu, il est donc possible qu'il y ait des bogues, qu'elles soient graphiques, entraînant un plantage, ou autorise / défende une action normalement possible dans le jeu original.
* Originalité * Originalité