Crash Bandicoot

- Code dans des H.
- Noms de variables peu clairs et mal choisies. Privilégiez des préfixes pour certaines parties du code genre Engine_Fnc1 et privilégiez des noms longs si obligé.
- Utilisation des GOTO abusive.
- Trop de variables globales non préfixées (évite des 'conflits' entre variables locales et globales).
- Plutôt const que static pour les sprites.
- Profiter de l'indentation.
- Eviter les boucles de blocages. Genre
while(!(_keytest(RR_ENTER) || _keytest(RR_ENTER1) || _keytest(RR_ENTER2)));
Ce temps perdu peut être utilisé dans des traitements ou autrement!
- Dans DEFINE_INT_HANDLER (fps_int), code bien trop complexe pour la requête à exécuter.
- Déclarations de variables toujours en tête de fonction jamais un peu partout.
- Dans char NEOCORTEX() grosse optimisation possible des déplacements. Eviter au max les répétitions de blocs presque identiques.
- Trop d'imbrications de if, esle if... Soit un switch ou optimisé bien mieux que ça!
- Eviter les lignes pptir-=(cgtir>-30 && cgtir<30)?5cgtir>-50 && cgtir<50)?4:3; quand cela n'est pas indispensable.
- Eviter de trop caster des pointeurs genre crashptr1=(unsigned long *)crash_d_C0; et éviter les pointeurs void *.
memcpy(lnsb,(spritecb[32]){{8, 1, 3500, 0, -40},
{8, 1, 3300, 0, -40}, {8, 1, 1150, 0, -40},
{8, 1, 780, 0, -40},
{8, 1, 310, 0, -40},
Code horrible, faire le tableau en constante globale!
- Privilégiez les défintiions (#define) au lieu des valeurs numériques pour certaines choses.
- Commenter les sources!!!

Expert 4
- Code non structuré. Code monolithique.
Pensez donc à découper votre programme en fichiers correspondant à des entités de votre jeu (gestion mémoire, structures de données abstraites, moteur, joueur, menus...).
- Les constantes devraient être en majuscules.
- Les définitions devraient figurer dans des fichiers h (en-têtes).
- Utilisez les types standards du C ou préférés des types faciles à lire.
char en S8, unsigned short en U16...
- Utilisation astucieuse des virgules fixes (pouvant faire l'objet d'une unité de compilation).
- Code dans les fonctions en bloc. Aucune séparation des parties.
- Pensez à stocker les messages du jeu assez longs à part.
En début de programme comme tableau constant de chaînes de caractères.
- La fonction p_choix_ptr est assez hasardeuse. il y a plus simple. en suivant le point précédent...
- Dans void _main(void) la gestion des touches pourrait se faire avec une table cela serait plus simple et plus rapide. De plus évitez les cascades de else puis if
préférez le code suivant:

if(touche==KEY_DOWNLEFT)
sel_meuble(225);
else if(touche==KEY_UPRIGHT)
sel_meuble(45);
else if(touche==KEY_DOWNRIGHT)
sel_meuble(315);
else if(touche==KEY_UPLEFT)
sel_meuble(135);
else if(touche==KEY_RIGHT)
sel_meuble(0);

voir encore mieux avec switch case
- Utilisez plus de défintions (#define). Les valeurs numériques sont dans la plupart des cas à bannir telles quelles dans un programme.
Ex:
x2=x+(b&MASK_BITS)-1;
if(x2>TI89_LCD_WIDTH-1)
{
aff_ligne_h(x,TI89_LCD_WIDTH-1,ADR_PIX(p_ecr_act,0,y,ecr_virt));
x2-=TI89_LCD_WIDTH, y++;
aff_ligne_h(0,x2,ADR_PIX(p_ecr_act,0,y,ecr_virt));
x=x2+1;
}

il faudrait donc utiliser

#define MASK_BITS 63
#define TI89_LCD_WIDTH 160
#define TI89_LCD_HEIGHT 100

Ce n'est qu'un simple exemple, le choix des noms pourrait être plus logique.

- Aucun commentaire. Ceci est très pénalisant si vous voulez reprendre facilement des parties de codes que vous avez programmées.

Mon avis est que ce projet manque tout de même d'organisation et de structuration malgré ça, certaines choses sont interessantes comme les virgules fixes.
Mais il faut avouer que coder un gros programme dans une seule unité de compilation devient vite pénalisant et bloque toute évolution.
Les bugs risquent de devenir assez fréquents, assez difficile à corriger...

F-Zéro
- Code très très bien organisé.
- Les sources sont optimisées.
- Aucun commentaire et les fonctions ne sont pas documentées.
typedef struct Machine { est inutile, typedef struct { suffit.

Peu de choses à dire dans le sens où les sources sont claires, faciles à lire, organisées...
Le gros repproche est que une documentation des sources est indispensable dans le sens où il y a de nombreuses fonctions et entités distinctes.
De plus le code devrait permettre la réutilisable, mode7, huffman. librairies distinctes. Orienté plus objets.

GUI89
- Sources organisés.
- Aucun commentaire.
- Les fonctions devraient être documentées.
- Les sources devraient se trouver dans des fichiers C et les déclarations dans des fichiers H.
- Le type void * devrait être remplacé par un autre type, généralement char *.
- Les structures devraient être en majuscules comme 'object', cela permet de ne pas avoir d'ambiguité dans les fonctions.

Mon avis est que ce programme est clair au niveau des sources mais pourrait être mieux organisé dans le sens où une unité de compilation pourrait correspondre à un contrôle (mouse, progressbar...).
De plus le code devrait être orienté objet (cela reste difficile mais possible en C).
Malgré ses points faibles, les sources sont propres et assez bien optimisées. Et surtout le pack est très complet!

Hawk
- Les sources devraient être dans des fichiers C et les déclarations dans des fichiers H.
- Le code est très bien organisé. Les parties du programme sont rapidement identifiables.
- void Attend(short temps) monopolise tout le processeur. Une interruption serait bien plus judiceux.
- Plus de commentaires et surtout une documentation pour chaque fonctions (paramètres...).

Mon avis est que ce programme est bien construit, bien entendu il n'est pas optimisé au max mais le code est clair, et facile à lire.

M4r10
- Beucoup de code dans static inline char PLAY(char readReplay) il faudrait plutôt couper le code en fonctions.
- Dans main.c les déclarations devraient être dans un ou plusieurs fichiers h.
- Code bien organisé.
- Les tableaux de données devraient être préfixés avec const.
- Peu de commentaires voir aucuns.

Mon avis est que ce programme est bien codé, bien organisé mais que certaines fonctions pourraient être découpées et que les sources devraient être commentées!

Star Castle
- Code organisé et clair.
- Utilisation astucieuse des virgules fixes.
- Peu de commentaires voir pas du tout.
- Il faudrait détailler chaque fonction.
- Certaines fonctions sont trop grosses niveau code, elles peuvent être découpées et donc faciliter la compréhension du code comme int Typhoon_Init(void).
- Utilisation astucieuse d'un fichier de données.
- Utilisation astucieuse de constantes.
- La structure TYPHOON peut être découpée pour faciliter la lecture du code. Evitez de concaténer des struct.
- Pensez dans les en-têtes à organiser mieux. Inclusions, macros au début suivies des structures, des typedef et enfin des déclarations. (Schéma standard mais pas forcément respecté dans certains cas).

Mon avis est que le code est propre, facile à lire, assez structuré et organisé mais manque cruellement de commentaires et d'une documentation courte pour chaque fonction.

- Eviter les boucles de blocages. Genre
while(!(_keytest(RR_ENTER) || _keytest(RR_ENTER1) || _keytest(RR_ENTER2)));
Ce temps perdu peut être utilisé dans des traitements ou autrement!

geogeo :
- Plutôt const que static pour les sprites.

- Eviter les boucles de blocages. Genre
while(!(_keytest(RR_ENTER) || _keytest(RR_ENTER1) || _keytest(RR_ENTER2)));
Ce temps perdu peut être utilisé dans des traitements ou autrement!

- Déclarations de variables toujours en tête de fonction jamais un peu partout.

- Pensez à stocker les messages du jeu assez longs à part.
En début de programme comme tableau constant de chaînes de caractères.

if(touche==KEY_DOWNLEFT)
[...]
voir encore mieux avec switch case

- Aucun commentaire et les fonctions ne sont pas documentées.
typedef struct Machine { est inutile, typedef struct { suffit.

- Le type void * devrait être remplacé par un autre type, généralement char *.