Règles de codage

Pourquoi des règles de codage ?

Maintenant que nous avons vu avec quelle facilité on peut manipuler ses données, il est tentant de s'en servir un peu partout à la demande.
Néanmoins, ce tutoriel a pour vocation de mettre en place un véritable projet.
Il est donc nécessaire de poser quelques règles pour faire du code propre et éviter le pire.

Les objectifs :

• Réutilisation : certaines partie du code peuvent être réutilisée dans d'autres projet ou pour d'autres extensions au site.
• Maintenance : au moment où on développer unprojet, on a l'ensemble de ce projet en tête, mais quelques mois plus tard, c'est oublié. Se plier à des règles permet de se retrouver beaucoup plus rapidement.
• Ouverture : des règles permettent de transmettre le projet à d'autres développeurs. Typiquement quand on n'a plus le temps ou que le projet prend une grand envergure et qu'il faut recruter.

Comment les atteindre

• Utilisation de convention de nommage
• Règles et contraintes d'utilisation des objets métier
• Une programmation défensive

Conventions de nommage

Pourquoi des conventions de nommage ?

La raison semble évidente, mais pour en savoir plus, le sujet est traité ici.

Quelles convention de nommage ?

• De manière générale, on utilise la notation camelCase pour tout nommer
• Les champs privés sont préfixés par un '_' pour les reconnaitres d'un coup d'oeil.
• Les variables locales et les paramètres commencent par une minuscule
• Les noms des classes, des évènement et des méthodes commencent par une majuscule
• Le nom d'une classe est un nom commun
• Le nom d'une classe ou d'une variable doit de préférence commencer par indiquer sa nature
  'Quoi' toujours en premier. Ca permet d'optimiser l'utilisation de l'intellisense.
  • ex : IdUser : c'est un identifiant pour un utilisateur
  • ex : UrlImage : c'est l'URL de l'image
• Le nom d'une méthode commence par un verbe
• On utilise les régions du C# pour séparer les classes en fonction de leur accessiblité

Contraintes sur les objets métiers

Masquer les constructeurs

Afin d'éviter qu'un développeur ne créé une instance inconsistente, on masque les constructeurs.
Le développeur devra passer par un jeu de methodes statiques pour récupérer une instance de travail.

Masquer les appels à la couche donnée

Seul le code de la couche métier doit avoir connaissance des mécanismes internes de persistence. Ceci permet de pouvoir changer ces mécanismes sans impact sur le reste du système.

Ainsi, les appels à MvcBlogEntities sont autorisés uniquement :

• Dans les tests unitaires
• Dans les classes de MvcBlog.Models
  • En particulier les classes contrôleur ne doivent jamais faire appel à MvcBlogEntities.
    • Contrôleur = gestion de l'interface
    • MvcBlogEntities = gestion de l'accès aux données
    • Ces deux couches ne doivent pas collaborer directement, c'est le modèle qui doit faire l'intermédiaire

Adopter de bonnes pratiques

On verra tout au long du déroulement un certain nombre de bonnes pratiques.
Celles-ci peuvent sembler contraignant, mais elles sont là pour faciliter le travail a prosteriori et permettre au développeur de se focaliser sur le travail à accomplir sans se prendre la tête sur des détail du code

La première de ces bonnes pratiques, c'est de n'utiliser qu'une seule instruction return dans une fonction.
On ne sais jamais quelle complexité peut prendre une fonction. Faire un unique return et des conditions de parcours de la méthode permet d'éviter d'avoir à comprendre tout le code de cette méthode pour s'assurer que le code que l'on rajoute soit bien exécuté.
Ainsi, une fonction a une entrée et une sortie. Pas de 'return' caché, pas de surprise.

Autre règle : un champ est toujours privé.
On doit passer par un accesseur (propriété) pour y accéder.
Au besoin, on peut coder un accesseur protégé, ou protéger le set de sa propriété.

Programmation défensive

Exceptions

A quelques rares exceptions, aucun objet de notre framework ne devra lancer d'exception.
On réservera ce mécanisme aux cas réellement exceptionnels, à savoir les cas non prévu par le développeur, ce qui est son but normal.
Beaucoup de développeurs se servent des exceptions pour remplacer la gestion d'erreur standard, mais ce ne sera pas notre cas.

Vérification de paramètres

Avant de commencer tout traitement, une méthode publique ou protégée, il faut vérifier la validité des paramètres fournis pour le bon déroulement du traitement.

Les méthodes privées n'étant appelée que depuis la classe, on admet que le développeur de cette classe aura fait la vérification avant d'effectuer l'appel

Log

Afin de tracer les erreurs, on effectuera des logs lors des situations qui demandent l'attention du développeur.
Pour ce faire, on utilisera une petite classe utilitaire que nous allons installer dans le projet à la fin de cet article.

Classes utilitaires

Téléchargement

1) Télécharger le zip ici, il contient quelques classes utilitaires pour la suite de notre projet.

Il contient en particulier :

• La classe Failer qui permet de faire des logs sur disque.
• La classe ConfigurationHelper qui facilite l'utilisation d'un fichier de configuration.

2) Créer un répertoire 'Code' dans la solution McvBlog

3) Ajouter les deux classes dans ce répertoire

Configuration

La classe Failer peut être configurée pour indiquer le répertoire dans lequel les logs sont créés

Pour cela rajouter la ligne suivante dans la section appSettings des fichiers de configuration des deux projets (n'oubliez pas le projet de test)

<appSettings>
    <!-- Répertoire contenant les logs d'erreur -->
    <add key="PathFailer" value="C:\temp\Logs\" />
</appSettings>