Je passe la majeure partie de mon temps de développement dans des fichiers XAML. Ils peuvent parfois devenir assez désordonnés. En C#, nous avons beaucoup de règles et de conventions, par exemple :

• Les recommandations de Microsoft pour développer des bibliothèques de classes,
• Les règles de codage .NET de SubMain,
• Les conventions C# de Philips.

J’ai donc rédigé une liste de règles que j’essaie de suivre chaque fois que je crée ou modifie un fichier XAML.

J’ai créé un dépôt Git, XAML Coding Guidelines, pour les rassembler. N’hésitez pas à ouvrir une issue si vous avez un argument à discuter ou une nouvelle règle à proposer.

Voici un extrait des règles au moment de la rédaction. Consultez le dépôt XAML Coding Guidelines pour lire la dernière version.

Merci à @julieknibbe, @carl_b_anderson, @LoicRebours et @ThomasNigro pour leur relecture !

Règles de codage XAML

Comment contribuer

Vous pouvez ouvrir une issue pour discuter d’une règle existante ou en proposer une nouvelle. Pour chaque proposition, fournissez au minimum :

• La cause.
• La description de la règle.
• Sa justification.
• La manière de corriger une violation.

Vous pouvez aussi ajouter un exemple de code qui enfreint la règle et sa version corrigée.

Vous souhaitez traduire ces règles dans une autre langue ?

Bien sûr ! Ouvrez une issue pour discuter de la manière de créer ensemble une version multilingue.

Principes des recommandations

• Être faciles à suivre : chaque règle doit être expliquée aussi simplement que possible. Une personne qui commence XAML doit pouvoir la suivre dès son premier jour.
• Être aussi peu controversées que possible : ces règles doivent éviter les débats de préférence. Nous ne sommes pas là pour décider si Visual Studio est mieux avec un thème blanc ou noir — conseil de pro : la bonne réponse est évidemment noir. Chaque règle doit donc avoir une justification. Les règles de StyleCop peuvent être une source d’inspiration.
• Être utilisables dans tous les projets XAML : Windows Phone, WPF ou applications universelles. Les règles doivent s’appliquer à tous. Une règle spécifique à une plateforme doit aller dans une section dédiée.

Règles

XA1x. Lisibilité du code

XA1001 — Un seul attribut par ligne

Cause

Plusieurs attributs sont déclarés sur la même ligne.

Description de la règle

Un élément enfreint cette règle lorsqu’il déclare plusieurs attributs sur la même ligne. Par exemple :

<Button x:Name="MyButton" Text="Hello world" Foreground="Blue"  />

On peut rapidement oublier des attributs, car l’éditeur XAML est souvent partagé entre la vue du code et celle du design. On pourrait adopter une règle précise, comme « limiter à 60 caractères par ligne » ou « deux attributs maximum par ligne ». Mais ces règles introduisent des cas particuliers et des interprétations qui les rendent plus difficiles à retenir. Mieux vaut appliquer une règle simple en permanence.

Comment corriger la violation

Placez un seul attribut par ligne.

Vous pouvez aussi utiliser le raccourci par défaut Ctrl+K, Ctrl+F pour formater automatiquement la sélection ou le document.

<Button x:Name="MyButton" 
        Text="Hello world" 
        Foreground="Blue"  />

XA1002 — Placer le premier attribut sur la ligne de l’élément

Cause

Un élément possède au moins un attribut, mais sa première ligne contient seulement le nom de l’élément.

Description de la règle

La règle est enfreinte lorsque l’élément est la seule chose déclarée sur la ligne.

<Button 
    x:Name="MyButton" 
    Text="Hello world" 
    Foreground="Blue"  />

Déclarer uniquement l’élément, sans attribut, produit trop de retours à la ligne lorsque celui-ci ne possède qu’un attribut. Nous ne pouvons pas créer une exception pour les déclarations avec un seul attribut.

De plus, placer les attributs sur les lignes suivantes peut conduire à une indentation alignée sous l’élément, qui n’est pas optimale pour la lecture.

Comment corriger la violation

Placez le premier attribut sur la même ligne que l’ouverture de l’élément.

<Button x:Name="MyButton" 
        Text="Hello world" 
        Foreground="Blue"  />

XA1003 — Trier les attributs d’un élément par ordre alphabétique

Cause

Les attributs d’une balise ne sont pas ordonnés.

<Button Text="Hello world" 
        Foreground="Blue"
        TextAlignment="Center"
        />

Description de la règle

La règle est enfreinte lorsque les attributs ne sont pas classés par ordre alphabétique dans la déclaration d’un élément.

Proposition et discussions en cours

Cette règle fait l’objet de discussions. Consultez la proposition correspondante.

Comment corriger la violation

Classez tous les attributs par ordre alphabétique, en respectant les règles associées.

<Button Foreground="Blue"
        Text="Hello world" 
        TextAlignment="Center"
        />

Règles associées

• XA1004 : placer x:Name ou x:Key en premier.
• XA1005 : placer les propriétés attachées au début de l’élément, après x:Name ou x:Key s’ils sont présents.

XA1004 — Placer x:Name ou x:Key en premier

Cause

Dans une balise qui déclare un attribut x:Name ou x:Key, celui-ci n’est pas déclaré en premier.

<Button Text="Hello world" 
        x:Name="ValidationButton"
        TextAlignment="Center"
        />

Description de la règle

Lorsqu’un élément déclare plusieurs attributs, dont x:Name ou x:Key, cet attribut doit être placé en premier.

Ces attributs sont plus importants que les autres, car :

• Ils identifient ce contrôle de manière unique.
• Ils indiquent que le contrôle est utilisé ailleurs : storyboard, code-behind, liaison de données, etc.

Les placer en tête aide à repérer ces contrôles et à les modifier avec précaution.

Règles associées

• XA1005 : placer les propriétés attachées au début de l’élément, après x:Name ou x:Key s’ils sont présents.
• XA2001 : nommer les éléments avec l’attribut x:Name.

Comment corriger la violation

Placez l’attribut x:Name ou x:Key en premier.

<Button x:Name="ValidationButton"
        Text="Hello world" 
        TextAlignment="Center"
        />

XA1005 — Placer les propriétés attachées en premier, après x:Name ou x:Key s’ils sont présents

Cause

Les propriétés attachées sont déclarées dans un ordre quelconque parmi les propriétés de l’élément.

<Button x:Name="ValidationButton"
        Text="Hello world" 
        Grid.Column="2"
        Grid.Row="0"
        TextAlignment="Center"
        />

Description de la règle

La règle est enfreinte lorsque les propriétés attachées ne sont pas déclarées avant tous les autres attributs, à l’exception de x:Name et x:Key.

Les propriétés attachées peuvent modifier l’apparence ou le comportement d’un contrôle et remplacer certaines de ses propriétés. Les déclarer en tête aide à identifier ces situations.

Comment corriger la violation

Placez toutes les propriétés attachées en premier, par ordre alphabétique. Si x:Name et x:Key sont déclarés, ils précèdent les propriétés attachées.

<Button x:Name="ValidationButton"
        Grid.Column="2"
        Grid.Row="0"
        Text="Hello world" 
        TextAlignment="Center"
        />

XA1006 — Utiliser une balise autofermante si l’élément n’a pas de contenu

Cause

Un élément utilise une balise de fermeture alors qu’il ne définit aucun élément enfant.

<Button x:Name="ValidationButton"
        Text="Hello world" 
        ></Button>

Description de la règle

La règle est enfreinte lorsqu’un élément sans enfant utilise une balise de fermeture distincte. Cela gaspille de l’espace.

Les éditeurs XAML de Visual Studio et de Blend permettent facilement de développer une balise autofermante lorsqu’on ajoute le premier enfant : ce n’est donc pas un argument pour conserver une fermeture séparée.

Comment corriger la violation

Utilisez une balise autofermante.

<Button x:Name="ValidationButton"
        Text="Hello world" 
        />

XA2x. Nommage

XA2001 — Nommer les éléments avec x:Name ou x:Key

Cause

Les attributs de nom ou de clé sont utilisés sans préfixe d’espace de noms.

<Button Name="ValidationButton"
        Text="Hello world" 
        />

Description de la règle

La règle est enfreinte lorsque Name ou Key est déclaré sans le préfixe x:.

Ces attributs sont plus importants que les autres, car :

• Ils identifient ce contrôle de manière unique.
• Ils indiquent que le contrôle est utilisé ailleurs : storyboard, code-behind, liaison de données, etc.

Rendre cet attribut plus visible grâce au préfixe aide à identifier ces contrôles et à les modifier avec précaution.

Comment corriger la violation

Déclarez toujours x:Name ou x:Key avec le préfixe x:.

<Button x:Name="ValidationButton"
        Text="Hello world" 
        />

XA2002 — Utiliser PascalCase

Cette règle est en cours de rédaction, dans l’attente de commentaires.

XA2003 — Ajouter au nom XAML un suffixe indiquant le type

Cause

Un élément est nommé sans indication de type.

<Button x:Name="Checkout"
        Text="Checkout" 
        />

Description de la règle

La règle est enfreinte lorsque le nom d’un élément ne se termine par aucune indication de son type.

Ce suffixe aide à repérer les membres de la classe de page ou de contrôle qui font partie de l’interface, et à comprendre ce que l’on peut en faire.

Comment corriger la violation

Ajoutez au nom de l’élément un suffixe indiquant son type.

<Button x:Name="CheckoutButton"
        Text="Checkout" 
        />

Règles associées

• XA2004 : ne pas utiliser un suffixe de type trop précis, sauf nécessité.

XA2004 — Ne pas utiliser un suffixe de type précis, sauf nécessité

Cause

Le nom d’un élément indique un type précis alors qu’aucun code n’utilise de propriété ou de méthode spécifique à ce type.

<StackPanel x:Name="ActionsStackPanel">
    ...
</StackPanel>

ActionsStackPanel.Opacity = 0;

Description de la règle

La règle est enfreinte lorsque le nom indique un type précis, mais que le code n’utilise que des propriétés ou méthodes définies dans une classe de base ou une interface.

Dans de nombreux cas, il n’est pas nécessaire de connaître le type exact. Prenons cet exemple :

<StackPanel x:Name="ActionsPanel">
    ...
</StackPanel>

Si ActionsPanel sert uniquement à changer la visibilité, ce nom convient. ActionsStackPanel donnerait trop de détails et empêcherait de remplacer ultérieurement le StackPanel par un Grid sans changer le nom.

En revanche, si vous modifiez la propriété Orientation quelque part, ActionsStackPanel est approprié : le nom doit indiquer que vous utilisez des propriétés propres à la classe StackPanel.

Comment corriger la violation

Retirez le suffixe indiquant le type précis.

XA2005 — Nommer uniquement les éléments utilisés dans le code-behind, une liaison d’élément ou une animation

Cause

Un élément définit un nom que personne n’utilise.

<StackPanel x:Name="ActionsPanel">
    ...
</StackPanel>

    ...

Description de la règle

La règle est enfreinte lorsqu’un élément définit x:Name ou x:Key, mais que ce nom ou cette clé n’est référencé ni dans le code-behind, ni dans une liaison d’élément, ni dans un storyboard.

Comment corriger la violation

Supprimez l’attribut x:Name ou x:Key.

<StackPanel>
    ...
</StackPanel>

XA3x. Maintenabilité

XA3001 — Utiliser la règle de trois pour décider si une valeur doit devenir une ressource

Cause

Une valeur de propriété est utilisée au moins trois fois.

Description de la règle

La règle est enfreinte lorsqu’une valeur est utilisée plus de deux fois à des endroits différents. Elle sera probablement réutilisée ailleurs. Pour améliorer la maintenabilité, il faut la déclarer comme ressource.

Comment corriger la violation

• Déplacez la valeur dans une ressource.
• Remplacez chaque utilisation par une référence StaticResource.

XA3002 — Placer tous les styles implicites en tête de fichier et les signaler par un commentaire

Cause

Un style implicite est déclaré ailleurs dans une page ou un dictionnaire de ressources.

Description de la règle

La règle est enfreinte lorsqu’un style implicite n’est pas déclaré en tête du fichier de page ou du dictionnaire de ressources.

Les styles implicites ne doivent être utilisés que lorsqu’ils s’appliquent à toute une page ou application. S’ils ne concernent qu’une partie, ils doivent être explicites.

Leur portée étant large, ils doivent être déclarés en premier et correctement commentés pour être bien visibles.

Comment corriger la violation

Si le style s’applique à tout le fichier :

• Déplacez sa déclaration au début de l’élément Resources.
• Ajoutez un commentaire avant la déclaration pour préciser son caractère implicite.

Si le style ne s’applique qu’à une partie du fichier :

• Rendez le style explicite.
• Ajoutez la référence au style dans chaque contrôle concerné.

XA4x. Organisation des fichiers de ressources

Les règles suivantes sont en cours de rédaction.

XA4001 — Placer les styles par défaut dans App.xaml et les autres dans un fichier distinct

XA4002 — Déclarer les éléments d’un fichier de ressources dans l’ordre suivant

<!-- #Constants -->
<!-- #Colors -->
<!-- #Brushes -->
<!-- #Converters -->
<!-- #Objects (such as Data) or commands (for ribbon),etc. -->
<!-- #Styles -->
<!-- #DataTemplates -->

Auteurs des recommandations

Consultez les contributeurs du dépôt.

Travaux en cours

Consultez les issues ouvertes.