Un code plus lisible
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.


novembre 20th, 2007 at 19:15
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.
novembre 20th, 2007 at 19:21
le commentaire doit répondre clairement à la question “pourquoi?”
le code doit répondre clairement à la question “comment?”
novembre 20th, 2007 at 19:22
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.