Différences

Ci-dessous, les différences entre deux révisions de la page.

--- faq:livre_blanc [2023/10/19 11:40] – créée CrazyCat
+++ faq:livre_blanc [2023/10/19 13:32] (Version actuelle) – [Conventions de nommage] CrazyCat
@@ Ligne 4: / Ligne 4: @@
 Que ce soit en TCL ou dans n'importe quel autre langage, vous devez vous créer et respecter des conventions de nommage, que ce soit pour les variables ou les procédures.
 <WRAP center round info 80%>
-Privilégiez l'anglais pour nommer vos variables, cela peut éviter certains problèmes
+Privilégiez l'anglais pour nommer vos variables et procédures, cela peut éviter certains problèmes. Mais prenez garde à ne pas utiliser de noms déjà existants, car TCL ne provoquera pas d'erreur.
 </WRAP>
-Un bon nom de variable doit permettre d'identifier rapidement son type((d'autant plus qu'en TCL, la plupart des variables sont simplement du texte)) et son utilité. Le nom doit être explicite tout en restant assez court.
+==== Variables ====
+  * Un bon nom de variable doit permettre d'identifier rapidement son type((d'autant plus qu'en TCL, la plupart des variables sont simplement du texte)) et son utilité. Le nom doit être explicite tout en restant assez court.
+  * L'utilisation du CamelCase est aussi une excellente idée, mais prenez bien garde: sur les systèmes *nix, l'interpréteur est sensible à la casse et `$sNick` ne sera pas équivalent à `$snick`.
+  * Autant que faire se peut, utilisez le même nom de variable lorsqu'elle a la même utilité
-L'utilisation du CamelCase est aussi une excellente idée, mais prenez bien garde: sur les systèmes *nix, l'interpréteur est sensible à la casse et `$sNick` ne sera pas équivalent à `$snick`.
+Exemple de convention
+  * débuter la variable par un identifiant de type (s pour une chaîne de caractères (//string//), i pour un entier(//integer//), a pour un tableau (//array//), l pour une liste, ...)
+  * décrire ce que contient la variable: nick pour un pseudonyme, channels pour une liste de canaux et channel pour un canal spécifique
+  * utiliser des variations sur le nom pour une meilleure description: nick sera le pseudonyme de la personne ayant déclenché la procédure, tnick (//target nick//) sera le pseudonyme de la cible, cnick (//current nick//) sera le pseudonyme en cours quand on parcourt une liste d'utilisateurs, ...
+Ce qui nous donnera donc:
+<code tcl>set lfriends
+# lfriend : liste des "amis"
+foreach scchannel [channels] {
+# scchannel : canal actuellement vu
+   foreach scnick [chanlist $scchannel] {
+# scnick : pseudo actuellement vu
+      if {$nick eq $scnick || [lsearch lfriends $scnick]>=0 } { continue }
+      append lfriends $scnick
+   }
+}</code>
+Vous constaterez que le CamelCase n'est pas utilisé dans ce bout de code: les variables sont suffisamment simple pour que l'on s'en passe. Mais nous aurions pu appeler la variable //lfriends// `lnicksInMyChans`.
+==== Procédures ====
+Comme pour les variables, les noms des procédures doivent être à la fois concis et explicites. Certains préconisent de les préfixer par le type de la donnée retournée, mais comme il est fréquent que les procédures ne renvoient rien (//void//) ou que le type soit variable, nous ne souscrivons pas à cette idée.
+Par contre vous pouvez tout à fait //regrouper//((entendez par là d'avoir des préfixes identiques)) les procédures de manière à mieux identifier leur champ d'actions.
+Ainsi, une procédure réagissant à un [[:scripts:binds#pub]] commencera par **pub.** (comme `pub.logMsg`) alors qu'une procédure agissant sur une base de données commencera par **db.** (comme `db.connect`). Notez aussi l'utilisation du <kbd>.</kbd> (point) comme séparateur plutôt que <kbd>:</kbd> (deux points). En effet, les <kbd>::</kbd> (double deux points) sont utilisés pour séparer les [[:tcl:namespace|espaces de nom]] et peuvent prêter à confusion, voir créer une erreur.
+{{tag> F.A.Q. Scripts}}