Question à 100€ : qu’est ce qui est le plus lisible ?
Difficile d’arriver à un code « parfait » qu’il est agréable de relire. Cependant un certain nombre de choses peuvent être améliorées à mon avis pour augmenter la lisibilité du code, l’aérer, et permettre d’arriver plus rapidement à l’essentiel de l’information.
Voici quelques points :
1./ une bonne utilisation des espaces !
On n’est pas payé à la ligne (hélas !) donc rien ne nous empêche d’aérer un peu le code.
Par exemple :
if ( maVar == 1 )
l’espace entre le if et la ( permet d’identifier immédiatement le type test, les espaces autour des parenthèses augmentent la lisibilité, l’opérateur ressort, …
De même pour la déclaration des fonctions…
function maFonc ( )
{
mon code…
}
l’espace entre les parenthèses même si l’on n’a pas de paramètre augmente la lisibilité.
La mise à la ligne de la première accolade permet de mieux délimiter le code.
2./ une bonne utilisation des indentations
Pour que les arguments fournis aux fonctions ou les valeurs des variables à un instant T soit visibles.
maVar1 = « ok »;
maFonc ( maVar1 );
3./ les paramètres dans les fonctions
ils doivent porter des noms de variables du type pMaVariable. Le « p » minuscule indiquant qu’il s’agit d’un paramètre
4./ les variables globales
pour l’as2 les variables globales doivent porter un nom du type gMaVariable.
5./ langue
toutes les variables et fonctions d’un projet doivent porter des noms cohérents, dans une seule langue choisie au préalable. Arrêtons avec les testMyVariable ( maVariable ) …
Vu la composition de notre équipe je préconise une utilisation massive du français.
6./ instructions conditionnelles
en ce qui concerne les instructions conditionnelles, essayons de réduire l’instruction if… else si nous n’avons qu’une ligne de traitement.
if ( test == 0 ) return true;
else return false;
switch ( maVariable )
{
case « évènement » :
goToAndPlay ( 1 );
break;
case « famille » :
goToAndPlay ( 2 );
break;
case « anniversaire » :
goToAndPlay ( 3 );
break;
default :
goToAndPlay ( 4 );
}
est plus élégant que
if ( maVariable == « évènement » )
{
goToAndPlay ( 1 );
}
else if ( maVariable == « famille » )
{
goToAndPlay ( 2 );
}
else if ( maVariable == « anniversaire » )
{
goToAndPlay ( 3 );
}
else
{
goToAndPlay ( 4 );
}
7./ commentaires
En ce qui concerne les commentaires, écrivons-en partout où le fonctionnement peut poser problème à un relecteur.
Utilisons les commentaires sous la forme
// mon commentaire sans accent et sans capitale au depart
Utilisons aussi l’instruction switch… case plutôt que d’utiliser de multiples if.

De plus, avec le nouveau FDT qui nous pose des warnings un peu partout prenons de bonnes habitudes :
par exemple : une fonction est censée ne rien renvoyer ? Déclarons-le => function ():Void
Enfin de façon plus générale, il faut aujourd’hui penser réutilisation et abstraction : le code doit pouvoir être réutilisé de façon propre voir inclus dans des classes réutilisables comme Pen.as.
le commentaire doit répondre clairement à la question « pourquoi? »
le code doit répondre clairement à la question « comment? »
et les commentaires avec
/**
*/
ou
///
sont compris par eclipse et documentent à la volée les méthodes et propriétés que l\’on écrit.