Standard De Programmation

VB.Net Standard et bonne méthode de programmation

Yannick Lapierre

Table des matières 1.Auteur...............................................................................................................................3 2.Introduction.......................................................................................................................3 3.Le but de standardiser le code et les meilleures pratiques................................................3 4.Convention de Nommage et Standard..............................................................................4 Règle de mise en majuscule............................................................................................4 Règles de mise en majuscules pour les identificateurs...............................................4 Règles de mise en majuscules pour les acronymes....................................................5 Règles de mise en majuscules pour les mots composés et les termes courants.........6 Respect de la casse.....................................................................................................7 Règle de nommage..........................................................................................................7 5.Indentation et espacement.................................................................................................8 6.Bonne technique de programmation...............................................................................10 7.Type de Données.............................................................................................................12 8.Le Logging (Debug).......................................................................................................13 9.Architecture.....................................................................................................................13 10.Commentaire.................................................................................................................14 11.Levé d'exception...........................................................................................................14 12.Les Évènements (Event)...............................................................................................16 13.Création d'interfaces utilisateur (Fome)........................................................................17 14.Annexe..........................................................................................................................19 Tableau de caractère spéciaux en XML........................................................................19

1.Auteur Ce document a était préparé par Yannick Lapierre. Ce document s'appuie sur celui réalisé sur dotnetspider.com.

2.Introduction Tout le monde peut écrire du code. Après quelques mois d'expériences en programmation, on peut écrire des applications qui 'fonctionnent', les faire fonctionner est simple, Mais le faire correctement demande plus de travail que juste les faire fonctionner. Sachez que la majorité des développeurs réalise du code qui 'fonctionne', Mais pas du 'bon' code. Écrire un 'bon' code est un art que vous devez apprendre et pratiquer. Tous le monde peut avoir une définition différente de ce qu'est un 'bon' code. Pour nous, un bon code doit respecter ces critères: ●

réutilisabilité

●

Maintenabilité

●

Efficacité

Certain développeur sont enclin à réaliser un code très performant, En sacrifiant le réutilisabilité et la maintenablilité, Mais en conciderant le retour sur investissement a long terme, efficacité et performance sont moins important que la ré utilisabilité et la maintenance. Si votre code n'est pas réutilisable, et maintenable, vous (et votre entreprise) allez 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.

3.Le but de standardiser le code et les meilleures pratiques Pour développer des applications fiables et maintenables, vous devez suivre des normes de codage et de bonnes pratiques. Les conventions de désignation(nommage), les normes(standards) de codage et les meilleures pratiques décrites dans ce document sont une compilation de notre expérience propre et en se référant aux méthodes de Microsoft. Yannick Lapierre

Il existe plusieurs normes dans l'industrie de programmation. Aucune d'elle n'est meilleurs que les autre, Vous pouvez suivre n'importe lequel d'entre elle. Ce qui est plus important est, de toujours suivre la même, je vous propose celle-ci

4.Convention de Nommage et Standard Note : Les thermes Ecriture Pascal et Ecriture Camel sont utiliser dans ce documents Écriture Pascal – Le 1er caractère de chaque mots Est en majuscule, les autres sont en minuscules. Exemple: BackC ackColor Écriture Camel – Le 1er caractère de chaque mots sauf le 1er est en majuscule, les autres sont en minuscules. Exemple: backC ackColor

Règle de mise en majuscule Cette section est en partie extraite du MSDN de Microsoft : Conventions de mise en majuscules

Règles de mise en majuscules pour les identificateurs Lorsqu'un identificateur se compose de plusieurs mots, n'utilisez pas de séparateurs, tels que les traits de soulignement (« _ ») ou les traits d'union (« - »), entre les mots. Utilisez plutôt la casse pour indiquer le début de chaque mot. Les instructions suivantes fournissent les règles générales relatives aux identificateurs. Utilisez la casse Pascal pour tous les noms d'espaces de noms, de types et de membres publics composés de plusieurs mots. Notez que cette règle ne s'applique pas aux champs d'instance. Pour les raisons décrites dans Instructions de conception des membres, vous ne devez pas utiliser des champs d'instance publics. Utilisez la casse Camel pour les noms de paramètres. Le tableau suivant récapitule les règles de mise en majuscules et donne des exemples pour différents types d'identificateurs.

Identificateur

Casse

Classe

Pascal

Type énumération

Pascal

Valeurs d'énumération

Pascal

Événement

Pascal

Classe d'exceptions Pascal Champ statique en lecture seule

Pascal

Interface

Pascal

Méthode

Pascal

Espace de noms

Pascal

Paramètre

Camel

Propriété

Pascal

Exemple public class HelloWorld Private Enum ErrorLevel Private Enum ErrorLevel FatalError End Enum Private Event ValueChanged public class WebException

RedValue

IDisposable Public Function ToString () as String System.Drawing Sub S (typeName as String) Public Property BackColor

Règles de mise en majuscules pour les acronymes Un acronyme est un mot composé de lettres de mots appartenant à une expression. Par exemple, HTML est l'acronyme de Hypertext Markup Language. Vous ne devez inclure des acronymes dans les identificateurs que dans le cas où ils sont connus et bien compris. Les acronymes diffèrent des abréviations en cela qu'une abréviation raccourcit un mot unique. Par exemple, ID est une abréviation de identifier. En général, les noms de bibliothèques ne doivent pas utiliser d'abréviations. Les deux abréviations qui peuvent être utilisées dans les identificateurs sont ID et OK. Dans le cas d'identificateurs utilisant la casse Pascal, elles doivent se présenter sous la forme Id et Ok. Si elles sont utilisées comme premier mot dans un identificateur à casse mixte, elles doivent se présenter respectivement sous la forme id et ok. La casse des acronymes dépend de la longueur de l'acronyme. Tous les acronymes

Yannick Lapierre

comportent au moins deux caractères. Pour les besoins de ces instructions, un acronyme de deux caractères est considéré comme un acronyme court et un acronyme de trois caractères ou plus comme un acronyme long. Les instructions suivantes spécifient la casse adaptée aux acronymes courts et longs. Les règles de casse des identificateurs priment les règles de casse des acronymes. Capitalisez les 2 caractères des acronymes de 2 caractères, sauf le premier mot d'un identificateur de casse Camel. Une propriété nommée DBRate est un exemple d'acronyme court (DB) utilisé comme premier mot d'un identificateur à casse Pascal. Un paramètre nommé ioChannel est un exemple d'acronyme court (IO) utilisé comme premier mot d'un identificateur à casse camel. Capitalisez uniquement le premier caractère des acronymes de trois caractères ou plus, sauf le premier mot d'un identificateur à casse camel. Une classe nommée XmlWriter est un exemple d'acronyme long utilisé comme premier mot d'un identificateur à casse camel. Un paramètre nommé htmlReader est un exemple d'acronyme long utilisé comme premier mot d'un identificateur à casse camel. Ne capitalisez aucun caractère d'acronymes, quelle que soit leur longueur, au début d'un identificateur à casse camel. Un paramètre nommé xmlStream est un exemple d'acronyme long (xml) utilisé comme premier mot d'un identificateur à casse camel. Un paramètre nommé dbServerName est un exemple d'acronyme court (db) utilisé comme premier mot d'un identificateur à casse camel.

Règles de mise en majuscules pour les mots composés et les termes courants Ne capitalisez pas chaque mot dans les mots composés fermés. Il s'agit de mots composés écrits comme un mot unique, par exemple « endpoint ». Par exemple, hashtable est un mot composé fermé qui doit être considéré comme un mot unique et avoir une casse appropriée. Dans la casse Pascal, il est présent sous la forme Hashtable et dans la casse camel, sous la forme hashtable Pour déterminer si un mot est un mot composé fermé, vérifiez un dictionnaire récent. La liste suivante identifie quelques termes courants qui ne sont pas des mots composés fermés. Le mot est affiché avec une casse Pascal, suivi de sa forme à casse mixte entre parenthèses. Pascal

Camel

BitFlag

bitFlag

Pascal

Camel

FileName

fileName

LogOff

logOff

LogOn

logOn

SignIn

signIn

SignOut

signOut

UserName

userName

WhiteSpace

whiteSpace

Respect de la casse Les instructions de mise en majuscules ont pour seul but de simplifier la lecture et l'identification des identificateurs. La casse ne peut pas être utilisée pour éviter des collisions de noms entre des éléments de bibliothèque. Ne supposez pas que tous les langages de programmation respectent la casse. Ce n'est pas le cas. La casse seule ne permet pas de distinguer les noms.

Règle de nommage 1. Utiliser l'écriture Pascal pour les Nom de Classes public class HelloWorld

2. Utiliser l'écriture Pascal pour les Nom de Fonctions (Procédure, Propriété) Sub SayHello(string name)

3. Utiliser l'écriture Camel pour les Variables et paramétré de fonction Dim totalCount as Integer = 0 Sub SayHello(string name) Dim fullMessage as string fullMessage = "Hello " & name End Sub

4. Utiliser le préfixe “I” avec une écriture pascal pour les Interfaces( Exemple: IEntity ) 5. Ne pas utiliser la notation Hongroise pour les nom de variables. Dans les années précédentes, la plupart des programmeurs aimaient avoir le le type de donnée dans le préfixe de la variable et utilisaient m_ comme préfixe des Yannick Lapierre

variable membre (Variable Privées) Private m_sName as String Public iAge as Integer Maintenant, ce n'est plus recommandé dans les standard de programmation .NET Il est toute fois recommandé des définir les variables privé relative a une classe en utilisant _ en préfixe de celle-ci (Voir plus bas) Private _salary as Integer

Utiliser des mots clair pour nommer une variable. Évitez les abréviations. Bien: Dim name as String Dim address as String Dim salary as String Mauvais: Dim nam as string Dim addr as String Dim sal as Integer 6. Ne pas utiliser de variable mono-caractère comme: i,

n, s etc. Utilisez de nom

comme: index, temp

Exception faite des variables utilisé pour les itérations et les boucles Dim i as Integer for i = 0 to count – 1 Next

7. Ne pas utiliser d'underscores (_) Pour le nom de variables locale (Dans un fonction) 8. Toutes les variables membres doivent être préfixe par un underscore (_) ce qui permet de le différencier des variables locales. 9. Préfixez les Variables,Propriété ou Fonctions retournant un

boolean par “is”.

Private _isFinished as Boolean Public Property IsFinished as Boolean

10. Le nom du fichier (code source) doit correspondre au nom de la classe. Pour le classe HelloWorld, le nom de fichier doit être helloworld.vb 11. Utiliser l'écriture Pascal pour les noms de fichiers.

5.Indentation et espacement

1. Utiliser TAB pour l'indentation Ne pas utiliser SPACES. Définir la taille de la tabulation à 2. 2. Les commentaires doivent être au même niveau d'indentation que le code, Bon:

' Boucle sur chaque éléments For i =0 to 20 ..... Next Mauvais: ' Boucle sur chaques élémens For i = 0 to 20 ... Next 3. Utiliser une ligne blanche pour séparer le groupe de code.

Bon: ' Ecrire le nombre de plans existants dans le premier champ fio.W(Count) ' Les champs qui suivent contient les noms de Cahiers For i = 0 To Count – 1 tmpStr = tab(i).Name fio.W(tmpStr, i + 1) Next i ' Fermer le fichier fio.FileClose()

Mauvais: 'Ecrire le nombre de plans existants dans le premier champ fio.W(Count) 'Les champs qui suivent contient les noms de Cahiers For i = 0 To Count – 1 tmpStr = tab(i).Name fio.W(tmpStr, i + 1) Next i 'Fermer le fichier fio.FileClose()

4. Il doit y avoir 1 et 1 seul ligne blanche entre chaque méthode d'une classe. 5. Utilisez #region pour regrouper les différentes partie de code.

Yannick Lapierre

6.Bonne technique de programmation 1. Le nom d'une fonction doit décrire ce que celle-ci doit faire. Bon: Sub SavePhoneNumber (phoneNumber as String) Mauvais Sub SaveDetails (phoneNumber as String) 2. Une méthode ne doit réaliser qu'un seul travail. Même si le travail est très court. 3. Toujours tester toutes les valeurs possibles. 4. Convertir les chaine de caractère (String) en minuscule ou majuscule avant de les comparer Sauf bien sur si la case a une importance. 5. Utiliser String.Empty a la place de “” Bon: If ( name = String.Empty ) Then mauvais:

If ( name = “” ) then

6. Utilisez enum lorsque c'est nécessaire. Ne pas utiliser de nombre ou de Chaine de caractère pour différencier des éléments. 7. Ne pas exposer des variable membre en dehors de la classe, Pour y accéder de l'extérieur, Exposez une propriété. 8. Ne pas mettre de code compliqué dans un événement, Appeler une fonction qui contient le code que l'événement doit exécuter. 9. Ne pas simuler un clique de bouton pour exécuter l'action que le clique sur le bouton va effectuer. Programmer une fonction, qui effectue le travail, et appeler la lorsque vous en avez besoin. 10. Ne jamais écrire en dur des chemin d'accès au fichier. 11. Ne jamais supposer que le programme va s'exécuter sur C: 12. Au démarrage de l'application effectuer quelque test, pour vérifier que tout les élément nécessaire sont bien présent, et dans le cas contraire prevenez l'utilisateur de ce qui manque. 13. Les message d'erreur doivent pouvoir aider l'utilisateur, Ne mettez pas de message du type : « Erreur dans l'application », ou « Une erreur c'est produite ». Écrivez plutôt : »MAJ de la base donnée impossible, vérifier que votre Login et Password sont correct » 14. Afficher un message cour et clair pour l'utilisateur, mais enregistrer, le maximum d'information pour vous permettre de comprendre d'où vient l'erreur. 15. Évitez les méthode public sauf si celle-ci doivent être utiliser a l'extérieur de la classe. Utiliser « Friend » Pour définir un méthode accessible uniquement dans l'assembly en cour. 16. Éviter de définir trop de paramètre pour une méthode, Si il y a plus de 5 paramètre, Il faut envisager de créer une classe ou une structure, pour recevoir ces donner, et passer celle-ci a la méthode. 17. Si vous avez une méthode qui retourne une collection, retournez une collection vide plutôt que « Nothing ». 18. Organiser intelligemment vous fichiers avec des répertoire appropriés. Ne pas dépasser un maximum de 10 répertoire a la racine, et ne pas dépasser une profondeur de 2 niveaux. Si vous êtes tenter de dépasser ces limites, c'est certainement que votre assembly peut être découper en plusieurs assembly plus simple. 19. Si vous ouvrez des sockets de connections a une base de donnée, un flux, etc Fermé toujours cette connections dans le block finally cela garantie la fermeture dans la connections en cas d'exception. 20. Déclarer les variables le plus près possible de leur utilisation. Déclarer une seul variable pas ligne. 21. Utiliser la classe StringBuilder a la place de String lorsque vous devez manipuler Yannick Lapierre

des objet String dans une boucle. A chaque fois que vous ajouter une string, l'objet string est détruit, et un nouvel objet String est crée, Cela consomme beaucoup de ressource inutilement. Prenez note de l'exemple:

public Function ComposeMessage (lines() as String) as String Dim message as String = String.Empty Dim i as Integer for i = 0 to lines.Length -1 message += lines (i) Next return message;f Dans l'exemple, il semble que l'on ne fasse que ajouter une chaine de caractère a une chaine existante. Mais en réalité l'objet string (Message) est détruit a chaque itération, et reconstruit avant que l'ajout ne se fasse. Si la boucle comporte beaucoup d'itération, Il vaut mieux utiliser la classe StringBuilder. voilà ce que cela donne.

public Function ComposeMessage (lines as String) as String Dim massage as new StringBuilder Dim i as Integer for i = 0 to lines.Length – 1 message.Append( lines(i) ) Next return message.ToString()

7.Type de Données L'utilisation du framework, et de .Net en général à conduit microsoft à définir un certain nombre de type comme étant des type commun au diffèrent langage de programmation. Il est donc recommandé d'utiliser de preference cest type. Cela est nécessaire pour réaliser des Classes « CLS Compiliant »,

Entier

Byte, Int16(Short), Int32(Integer), Int64(Long)

Decimal

Single, Double, Decimal

Caractere

Char, String

Autre

IntPtr, Boolean

8.Le Logging (Debug) Le tracking de bug est la principale difficulté lorsqu'une application est en production (ou en phase de test). Si une partie des bugg vont être traqué avec des test unitaires et des test d 'utilisation, il est tres probable que des bugg passent au travers du filet, et ceux ci seront très difficile a traqué lorsqu'ils arrivent chez l'utilisateur final. Un des outils permettant de comprendre l'origine d'un bugg coté client, est de loggué les actions de l'application. Et la aussi il y a des bonne pratiques, mais surtout des choses à éviter. L'utilisation de « Debug.Print » est la 1ere étape de logging, Mais cela reste tres limité. Heureusement, il existe plusieurs système de logging plus développé (Nlog, Log4Net,...). Ces système permettent de loguer les message dans diffèrent conteneur : Fichier base de donnée, et même flux de donnée. Ces loguer définissent plusieurs niveau d'importance du message. Cela va du niveau « Fatal » au niveau « Trace ». Il est possible de choisir le niveau importance a partir du quel les messages vont être Logguer, cette hiérarchisation permet d'éviter de logguer trop de message en utilisation normal, mais de pouvoir l'augmenter en cas de besoin. La 1ere erreur a ne pas faire, et de définir trop de niveau d'importance. •

Trace – Niveau le plus détaillé, génère beaucoup de message

•

Debug -Niveau de détail basique, ce niveau doit permettre de suive l'évolution de l'application,

•

Info – Message d'information

•

Warn – Message d'avertissement, non affiché au l'utilisateur final

•

Error – Message d'erreurs

•

Fatal – Message d'erreur Fatal, L'application a de grande chance de se terminer.

9.Architecture 1. Utiliser toujours des architectures multi couches (N-Tier). 2. Ne jamais accéder a une base de donnée depuis l'interface utilisateur. Toujours utiliser une classe de donnée qui va réaliser toutes les opération avec la base de Yannick Lapierre

donnée. Cela simplifie le support et la migration vers une autre base de donnée. 3. Utiliser des Try-Catch dans la couche de données pour intercepter toutes les exception liées a la base de donnée. Cela doit servir a enregistrer les erreur. Cet enregistrement doit inclure le nom de la commande exécute, le nom de la procédure stocké, les paramètre, le chaine de connections etc . Après l'enregistrement, il faut déclencher une nouvelle exception, pour que la couche du dessus puisse intercepter l'exception, et agir en conséquence. 4. Séparez votre application en plusieurs assembly, regroupez dans une librairie particulière tout les utilitaire indépendant. Tout les fichier relatifs au base de donnée peuvent être placé dans une libraire séparé.

10.Commentaire De bon et utiles commentaire vont donner au code une meilleur maintenabilitée. 1. Ne pas commenter chaque ligne de code ni chaque variable déclaré. 2. Écrire des commentaire uniquement la ou ils sont nécessaire. Mais un code correctement lisible ne demandera que peu de commentaire. 3. Si vous avez une partie de code complexe, documenter la correctement avec suffisamment d'information. 4. Si vous initialiser une variable numérique a une autre valeur que 0, documenter la raison de cette nécessite.

11.Levé d'exception Les exception sont une part importante de la programmation, pour obtenir un code stable, 1. Ne jamais intercepter une exception, et ne rien faire lors de l'interception. En faisant cela vous masquez l'exception, et vous ne saurez jamais si l'exception se déclenche ou non. Dans la plupart des cas vous effectuerez un enregistrement de l'exception, et poursuivrez l'exécution du code. 2. Toujours intercepter une exception spécifique. Ne jamais intercepter une exception générique Bon:

Sub ReadFromFile (fileName as String) try ' read from file. catch (ex as FileIOException) // log error. // re-throw exception depending on your case. Throw End Try End sub Mauvais: Sub ReadFromFile (fileName as String) try ' read from file. catch (Ex as Exception) ' Catching general exception is bad... we will never know whether ' it was a file error or some other error. ' Here you are hiding an exception. ' In this case no one will ever know that an exception happened. End Try return "" 3. Vous ne devez pas intercepter les exception général dans toutes les méthode. Laisser le code planter. Cela vous permettra de détecter plus d'erreur durant le cycle de développement. Vous pouvez avoir une couche de traitement des erreur, ou vous allez traiter l'erreur générique, en affichant un message compréhensible a l'utilisateur avant de fermer l'application ou de permettre a l'utilisateur d'ignorer le problème et de continuer. 4. Lorsque vous propager une erreur utilisez throw sans spécifier l'exception d'origine. Dans ce cas, la pile d'appel (call stack) original est préservé. Bon: Try ..... catch ' do whatever you want to handle the exception throw End Try Mauvais :

Yannick Lapierre

Try ..... catch (Ex as Exception) 'do whatever you want to handle the exception Throw ex End Try 5. N'utiliser les exception que pour le cas ou il est impossible de savoir d'une autre manière si une erreur va se produire. Certains développeur utilise un -Try-Catch lors de l'insertion d'une ligne dans une base de donnée pour savoir si la ligne existe déjà. C'est une chose a ne pas faire. Il est possible de tester l'existence de la ligne par une requête SQL. La levé d'exception est une opération qui demande beaucoup de Cycle CPU, et qui ne doit être utilisé que pour les cas extrême. 6. Ne jamais écrire de grand bloc dans le Try-Catch. Si cela était nécessaire, effectuer un Try-Catch pour chaque action de votre code. Cela permettra de donner un message d'erreur plus précis a l'utilisateur, ainsi que la couche de traitement d'erreur. Depuis VS 2008 en AddIns et dans VS 2010 en version final, Microsoft a introduit la notion de code Contract. Cette notion est appelée à remplacer une partie des exceptions (celles liées entre autre aux valeurs des paramètres de méthodes), mais il n'existe pas encore de bonne pratiques à leurs utilisation.

12.Les Évènements (Event) Les évènement ont une place importante dans le développement en .Net Il y a ici encore plusieurs façons de travailler avec les évènements. Et certains raccourci, qu'il est recommandé de ne pas suivre. 1. Ne jamais appeler directement l'event, mais ça méthode associé, En effet, la solution simple est de définir sont event, et de l'appeler directement dans le code a l'endroit voulue. Or cette solution est un faux ami, car elle ne permet pas de rajouter ultérieurement du code dans l'event lui même. Il faut donc créer un event (MonEvent) et lui associer une méthode privée portant le nom de l'event précédé de « On » (OnMonEvent). Et dans le code appeler la méthode plutôt que l'event. A ne pas faire : Public Event MonEvent(ByVal sender As Object, ByVal e As EventArgs) Public Sub MaSub() RaiseEvent MonEvent(Me, New EventArgs) End Sub Bonne façon de faire

Public Event MonEvent(ByVal sender As Object, ByVal e As EventArgs) Private Sub OnMonEvent(ByVal e As EventArgs) RaiseEvent MonEvent(Me, e) End Sub Public Sub MaSub() OnMonEvent(New EventArgs) End Sub Pour les personnes utilisant Le Framework 2,0 ou + de Microsoft, il est même recommandé d'écrire cela de la manière suivante: Public Event MonEvent As EventHandler(Of EventArgs) Private Sub OnMonEvent(ByVal e As EventArgs) RaiseEvent MonEvent(Me, e) End Sub Public Sub MaSub() OnMonEvent(New EventArgs) End Sub 13.Création d'interfaces utilisateur (Fome) Une interface utilisateur est en fait une classe (dérivant de la classe form), qui va présenter à l'utilisateur des controls (Textbox, combobox, Datagrid, …). Il existe des bonnes pratique a avoir pour réaliser des interfaces correcte du point de vue code. 1. Utilisez des préfixe appropriés pour les éléments d'interfaces (Voir tableau) 2. Tous les controls doivent avoir un nom explicite, même les labels. 3. Il est très peu recommandé de mettre en dur les textes a afficher a l'utilisateur. Dans touts les cas, il ne faut traiter les textes en 2 étapes: - Mettre un texte explicite précédé de « _ » dans la partie texte de l'objet au niveau du concepteur graphique. Cela va vous permettre d'avoir une forme clair en mode création. - créer une méthode qui remplie les textes utilisateur, c'est à ce niveau que vous pourrez appeler les textes depuis une base de donné, un fichier, ou même l'écrire en dur, Mais vous aurez au moins regroupé a un endroits unique tout les textes présenté a l'utilisateur. Cela simplifie les changement de texte. Car on a toujours le cas ou le bouton « Valider » se retrouve renommé en « Accepté » une fois l'application fini. Le « _ » en préfixe dans la partie écrite en dure vous permettra de voir en exécution les composant que vous avez omis d'ajouter dans la méthode de remplissage des textes.

Yannick Lapierre

Private Sub Frm_Parameters_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load LoadText()

End Sub

Private Sub LoadText() lab_CurrentUserID.Text = "Identifiant de l'utilisateur courant" ttp_General.SetToolTip(lab_CurrentUserID, "L'identifiant de l'utilisateur courant, permet au système de l'identifier de manière unique") End Sub

Préfixe

Control

Préfixe

Control

Label

lbl_

CheckedListBox

chklst_

TextBox

txt_

RadioButton

rad_

DataGrid

dtg_

ProgressBar

pb_

Button

cmd_

Image

img_

LinkLabel

lnk_

Panel

pan_

ListView

lv_

GroupBox

gb_

ComboBox

cbx_

TabControl

tab_

ListBox

lst_

TabPage

tabp_

TreeView

tv_

DataSet

ds_

DateTimePicker

dtp_

DataTable

dt_

Checkbox

chk_

ErrorProvider

erp_

14.Annexe

Tableau de caractère spéciaux en XML Caractère " & € ‹ › œ Ÿ espace ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ ® ¯ ° ± ² ³ ´ µ ¶ · ¸

XML " & € < > œ Ÿ   ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ ­ ® &masr; ° ± ² ³ ´ µ ¶ · ¸

Yannick Lapierre

¹ º » ¼ ½ ¾ ¿ À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï Ð Ñ Ò Ó Ô Õ Ö × Ø Ù

¹ º » ¼ ½ ¾ ¿ À Á Â Ã Ä Å &Aelig Ç È É Ê Ë Ì Í Î Ï ð Ñ Ò Ó Ô Õ Ö × Ø Ù

Ú Û Ü Ý Þ ß à á â ã ä å æ ç è é ê ë ì í î ï ð ñ ò ó ô õ ö ÷ ø ù ú

Ú Û Ü Ý þ ß à á â ã ä å æ ç è é ê ë ì í î ï ð ñ ò ó ô õ ö ÷ ø ù ú

û ü

û ü

ý þ

ý þ

ÿ

ÿ