Affichage des articles dont le libellé est Commentaires. Afficher tous les articles
Affichage des articles dont le libellé est Commentaires. Afficher tous les articles

lundi 7 mai 2012

Truc pour organiser le code C#

Le C# (et aussi le C++) offre une instruction de précompilation fort utile pour organiser le code: #region. Cette commande spécifie un bloc de code que vous pouvez réduire ou développer en cliquant sur le - ou + à la gauche de la page d'édition. Une région se termine par la commande #endregion. Voici un exemple dans MonoDevelop:
Cliquer sur l'image pour l'agrandir.
Une région Logical Operators a été créée avec les commandes #region et #endregion. Un petit symbole - entouré d'un carré est à la gauche de la commande #region et permet de réduire ce bloc de code. Une fois réduit, le code ressemble à ceci:
Cliquer sur l'image pour l'agrandir.
Les fonctions à l'intérieur de la région ont disparu et sont remplacées par une étiquette indiquant Logical Operators. MonoDevelop ajoute automatiquement dans le haut à droite une liste des régions définies par l'utilisateur.
La liste des régions.
En cliquant sur un élément de la liste, MonoDevelop place le curseur au début de la région. Très utile pour naviguer rapidement dans le code. De plus, MonoDevelop ajoute les régions dans le Document Outline et regroupe les fonctions de chaque région.

Il est possible d'imbriqués les régions. Par exemple, ajoutons une région Bidon qui entoure la région Logical Operators:
Cliquer sur l'image pour l'agrandir.
Deux icônes d'offuscation apparaissent comme attendu. Par contre, voici deux comportements inattendus et désagréables:
  1.  La liste des régions n'est pas imbriquée. La région Bidon apparaît après la région Logical Operators!
  2. Dans le Document Outline, la région Logical Operators a été remplacée par la région Bidon
MonoDevelop ne semble pas supporter complètement les régions imbriquées. Je ne sais pas quand le problème sera réglé. Si quelqu'un est au courant du développement de MonoDevelop et connaît la réponse, faites-le-moi savoir.

vendredi 4 mai 2012

Comment documenter les scripts dans Unity?

Les commentaires dans les scripts sont importants pour expliquer leur fonctionnement. L'utilisation des commentaires varie d'une école de pensée à une autre. Certains prônent l'utilisation massive de commentaires pour expliquer les intentions du code. D'autres croient que le code devrait être auto explicatif et libre de commentaires. Ma position sur le sujet est mitoyenne. J'utilise des noms de fonctions et de variables évocatrices, claires et indiquant leur fonction le plus souvent possible. Malgré tout, si je ne commente pas régulièrement, j'ai de la difficulté à saisir mon propre code après quelques mois. Alors, je documente.

L'ajout d'un commentaire se fait en ajoutant deux barres obliques "//":
//Un commentaire vraiment inutile.
string action = "Commente moi!"
ou pour un bloc de commentaires, avec "/*" et "*/":
/*
Il était une fois, dans l'ouest, une princesse prisonnière
dans une taverne miteuse gardée par des truands à la peau
tannée par le soleil et au regard sauvage, etc., etc., etc.
*/
string action = "Commente, mais commente égal!"
et aussi avec "///":
///Parce que // fait tellement 1990.
string action = "Commente moi!"

Dans MonoDevelop, si vous tapez "///" avant une entité (une variable, une fonction, une classe, etc.) vous obtenez:
/// 
/// Du XML???
/// 
private string action = "Commente moi!" 
MonoDevelop crée un commentaire avec un tag XML. Ce code XML est utilisé par un programme externe pour générer automatiquement la documentation. Les générateurs de documentation sont des programmes qui lisent le code source et les commentaires, l'analysent et retournent une documentation en format texte, HTML, XML, Latex, etc. qu'il est possible de consulter et d'effectuer des recherches. C'est très pratique pour se retrouver dans un gros projet avec des centaines de scripts. Mon générateur de documentation favori est Doxygen. Je vais parler de Doxygen dans un prochain billet.

L'utilisation du système de documentation avec l'XML amène un autre énorme avantage, en plus de la génération automatique de la documentation. Si vous glisser votre souris au-dessus d'une entité du code (une variable, une fonction, un enum, etc.), une info bulle jaune apparaît qui ressemble à ceci:

L'information de cet encadré n'est pas très utile. Nous apprenons que _selected est un booléen. Avec l'ajout d'un commentaire XML, voici le résultat:
Notre commentaire apparaît dans l'info bulle jaune! Cette description va apparaître si le curseur glisse au-dessus de la variable _selected quel que soit sa position dans le code. Si une variable publique est commentée, la description va aussi apparaître si la variable est utilisée dans une autre classe. Ce petit encadré peut sauver du temps. Imaginer que vous êtes dans le code. Vous travaillez sur une fonction, mais vous ne vous souvenez plus de l'intention d'une fonction ou de ce que stocke une variable. Normalement, vous naviguez dans le code, allez à la fonction ou à la variable, lisez la description et revenez à votre fonction. C'est long et inutile. Avec les commentaires XML, glisser le curseur sur la variable ou la fonction mystérieuse et voilà la description (si bien sur vous l'avez documentée).

Les commentaires en XML sont plus longs que les commentaires normaux, mais je recommande de les utiliser systématiquement pour permettre de générer la doc automatiquement et pour les info bulles. La longueur des commentaires n'est pas un problème réel avec les éditeurs modernes. Mono Develop permet de cacher les commentaires en appuyant sur le symbole +:
Avant.
Après.
Peu importe la longueur du commentaire, une fois refermé, il ne prendra qu'une ligne, vous permettant de lire le code sans obstruction.