Du « bon » code

Tout le monde peut écrire du code, mais la majorité des développeurs réalisent du code qui « fonctionne », mais pas du « bon » code. Produire cela, c’est un art que vous devez apprendre et pratiquer.

La technique

Tout le monde peut avoir une définition différente de ce qu’est un bon code. Pour nous, un bon code doit respecter les critères suivants :

· Réutilisabilité

· Maintenabilité

· Efficacité

Certains programmeurs exploitent trop le dernier critère qu’est l’efficacité, au détriment de la réutilisabilité et de la maintenabilité. Si l’on considère le retour sur investissement à long terme, efficacité et performance sont moins importantes que la réutilisabilité et la maintenance.

Il coûte moins cher d’augmenter la puissance d’une machine tous les 5 ans plutôt que de devoir dépenser du temps et de l’argent pour identifier les problèmes, essayer de comprendre le code et ce tout au long du cycle de vie de l’application.

Convention de nommage et standard

Il existe deux conventions d’écritures plus célèbres que les autres. Les méthodes Pascal et Camel.

Écriture Pascal – Le 1^er caractère de chaque mot est en majuscule, les autres en minuscules.

Exemple : BackColor

Écriture Camel – Le 1^er caractère de chaque mot sauf le 1^er mot est en majuscule, les autres sont en minuscules.

Exemple : backColor

La meilleure méthode est de mélanger les deux écritures pour se faire une règle de nommage.

Règle de nommage

Ø Utiliser l’écriture Pascal pour les noms de Classes, de fonctions (procédures, méthodes, propriétés);

Ø Utiliser l’écriture Camel pour les Variables et paramètres de fonction;

Ø Utiliser le préfixe « I » avec l’écriture Pascal pour les Interfaces Ex. : IEntity;

Ø Préfixez les variables, propriétés ou fonctions retournant un boolean par «is»;

Ø Utiliser des mots clairs pour nommer une variable. Évitez les abréviations.

dossierSource au lieu de dossSour

Attention : Ne pas utiliser la notation hongroise. Anciennement, les programmeurs aimaient avoir le type de donnée dans le préfixe et utilisaient m_ comme préfixe des variables membre (variables privées).

Maintenant, ce n’est plus recommandé dans le standard de programmation .NET

Il est toutefois recommandé de définir les variables privées relatives à une classe en utilisant le préfixe « _ »

Identificateur	Exemple
Classe	Public Class HelloWorld
Type d’énumération	Enum NiveauErreur
Valeurs d’énumération	Enum NiveauErreur FatalError End Enum
Évènement	Private Event ValueChanged
Interface	IDisposable
Méthode	Public Function ToString() as String
Paramètre	Sub S (typeName as String)
Propriété	Public Property BackColor
Variable	Dim pleinePage As String = 0
Variable globale	Dim _pleinePage As String

Exemple:

Dim _nombreMaximal As Integer = 0

Sub DireBonjour(ByVal nom As String)

Dim pleinePage As String

pleinePage = « Bonjour «  & name

End Sub

La casse des acronymes

Les acronymes courts (au moins 2 caractères) doivent être en majuscules et les acronymes long (3 caractères et plus) doivent être considérés comme un mot normal.

Exemple les classes: IORead et XmlReader

Attention : Inclure des acronymes que s’ils sont connus et bien compris par tous.

Présentation du code

Ø Utiliser TAB pour l’indentation Ne pas utiliser SPACES;

Ø Définir la taille de tabulation à 2;

Ø Les commentaires doivent être au même niveau d’indentation que le code;

Ø Utiliser une ligne blanche pour séparer le groupe de code commenté;

Ø Il doit y avoir 1 ligne et 1 seule entre les méthodes d’une classe;

Ø Utilisez #Region pour regrouper les différentes parties de code de même type

Bonne programmation

Ø Le nom d’une fonction doit décrire ce que celle-ci fait;

Ø Une méthode doit faire qu’un seul travail, même si celui-ci est très court;

Ø Toujours tester toutes les valeurs possibles;

Ø Convertir les chaînes de caractère en minuscules avant de les comparer Sauf si la casse est importante;

Ø Utiliser String.Empty au lieu de «  » Ex : if (name = String.Empty) Then;

Ø Utiliser Enum lorsque c’est nécessaire, ne pas utiliser de nombre ou de caractère pour différencier les éléments;

Ø Ne pas exposer les variables à l’extérieur, Exposez une propriété;

Ø Ne pas mettre de code compliqué dans un évènement, Appelez une fonction qui fait le travail;

Ø Éviter de définir trop de paramètres pour une méthode, Si il y en a plus de 5, envisagez de créer une classe ou une structure et de passer celle-ci;

Ø Si vous avez une méthode qui retourne une collection, retournez celle-ci vide plutôt que Nothing;

Ø Si vous ouvrez des sockets de connexion, fermez toujours ceux-ci dans un bloque Finally, cela garantit la fermeture en cas d’exceptions;

Ø Déclarez les variables le plus près possible de leur utilisation. Une seule déclaration par ligne;

Commentaire

De bons et utiles commentaires vont donner au code une meilleure maintenabilité.

Ø Ne pas commenter chaque ligne de code ni chaque variable déclarée;

Ø Écrire des commentaires uniquement là où ils sont nécessaires. Mais un code correctement lisible ne demandera que peu de commentaire;

Ø Si vous avez une partie de code complexe, documenter la correctement avec suffisamment d’information.

Ø Si vous initialisez une variable numérique à une autre valeur que 0, documentez la raison de cette nécessité

Exceptions

Utilisez Throw sans spécifier l’exception d’origine, cela préserve le call stack, (pile d’appel).