Suite à une discussion sur les variables, la façon d’organiser le code, ... (sujet déclaration de variable globale) voici un exemple de convention de nommage assez complet. Chacun a ses habitudes et je ne prétend pas qu’il soit pafait. Je l’utilise tous les jours et j’avoue qu’il m’approte toute la lisibilité souhaitable qui me permet d’organiser mon code.

voilà :

A.) nommage des variables

Les variables sont multipréfixées, les préfixes étant en minuscules. Le radical de la variable étant lui en minuscule avec chaque première lettre de mot en majuscule (asuf pseudo-constantes, cf ci dessous)

A1) préfixe de portée

le premier préfixe utilisé définit la portée de la variable :

* globale : g

* instance : p

* authoring : __

les variables d’authoring (définies par getPropertyDescriptionList) ayant un comportement particulier, elles sont considérées comme constantes et privées.

* temporaire : RIEN ou t

(t étant utilisée essentiellement lorsque le type de la variable est changeant, et donc impossible à définir dans le second préfixe)

* arguments de méthode : rien ou a (a étant utilisé lorsque le tpe est variable, et donc impossible à indiquer dans le second préfixe)

* script : _ Ceci est le cas très particuliers de propriétés de script non instancié.

A2) préfixe de typage

le second préfixe définit le type de la variable (si possible, donc parfois absent, par exemple pour les paramètres passés à une méthode qui supporte la surchage)

Voici la liste (non exhaustive) des principaux préfixes utilisés

* n : entier

* f : flottant

* b : booléen

* y : symbole

* str : chaine

* xy : point

* r : rectangle

* v : vecteur 3D

* w : acteur 3D (member, mais avec un type particulier)

* l : liste linéaire ou de propriétés

* m : acteur

* sp : image-objet

* o : instance

* sc : script

* c : couleur

* i : objet-image

* snd : objet son (sound(n))

* w : fenêtre

* hk : scène physique Havok

* sh : shader

* tx : texture

* cam : camera

* lg : lumière (lg étant une combinaison autrement impossible, ce qui n’est pas le cas de li)

* mr : modelResource (idem : mr n’est pas une combinaison possible à partir de m)

* ref : #ref d’un text

* d : objet date

Ce second préfixe est cumulatif, par exemple une liste d’entiers aura pour préfixe ’ln’

Cas particulier : les quads.

Bien que les quads soient des listes, leur formatage particulier m’incite souvent à les différencier d’une banale liste. Dans ce cas ils auront le préfixe ’q’

Cas particuliers : les pseudo constantes

Il peut-être très intéressant d’avoir des constantes.

Lingo ne permettant pas de définir de vraies constantes, il faut avoir une convention particulière et de la discipline pour pouvoir disposer de constantes.

Dans ce cas, le préfixe de typage sera précéde de K, et le radical de la variable sera alors écrit tout en majuscules, les mots étant séparés de ’_’.

Par exemple la couleur de fond constantes, définies pour l’instance, sera pKc_BACKGROUND_COLOR.

Cas problématiques : je suis ouvert à toute proposition pour les quelques types me posant des problèmes :

* group dans un acteur 3D (gr étant un rectangle global)

* light (li n’étant pas la panacée)

* castlib (c étant reservé pour couleur, cast étant long...)

* timeout (je n’aime pas to, et je n’ai encore rien trouvé d’autre... mais le problème se pose moins puisque _tout_ mes timeouts sont englobés dans l’un de mes 2 scripts parents reservés à cet usage.)

B.) nommage des méthodes

B1) méthodes d’animation

* Seule convention : première lettre en majuscule. (par exemple SearchAndReplace() )

* Pour les méthodes pseudo-protected (méthode d’animation nécessaire pour une autre méthode d’animation, mais non destinées à être publique), le préfixe _ est utilisée (ex : _FonctionRecursiveNecessairePourUneFonctionPublique() )

Cas particuliers : Certaines méthodes de ’wrap’ (enrobage) des méthodes système. Par exemple un wrapper de timeout sera appellé _Timeout(..), de même on pourra avoir un _Cursor(..) qui enrobera la commande générique Lingo cursor et apportera peut-être des options supplémentaires.

B2) Méthodes d’instances

Les noms des méthodes d’instances sont préfixées suivant leur portée, essentiellement pulique ou privée.

* m pour les méthodes publiques

* mi ou _ pour les méthodes privées (essentiellement ’mi’. Le ’_’ sera utilisé plus particulierement dans des cas de méthodes protected : méthode spubliques seulement pour certaines instances dans notre chaine d’ancètres.

* _ pour les méthodes de pseudo-surcharge. Par exemple on pourra trouver dans des scripts des méthodes _mouseUp (qui seront appellées et par mouseUp et par mouseUpOutside et par des simulateurs de souris), des méthodes _updateFrame, appellées ou non par les gestionnaire exitFrame, prepareFrame, ou par des timeout pour des mises à jour asynchrones.

javascript:barre_raccourci(’

’,’

’,document.formulaire.texte)

Cas particuliers :

Les script parents non destiné à être instancié, par exemple des conteneurs de données, n’auront pas forcemment de préfixe. Leur role revient en fait à avoir des méthodes d’animation ’packagées’. On utilisera donc par exemple lDatas = script("UnScriptParentNonInstanciable").GetData() De tels scripts parents peuvent être utiliser pour définir des constantes ou des paramètres, ou pour sauvegarder une partie, un état, un document, ...

Pour nous permettre d’avoir des scripts très évolutifs au cours de la vie de leur instances, tous les scripts sont équipés de mécanismes génériques pour peremttre le chainage d’ancètres. Ainsi nous ne ferons jamais directement me.ancestor = oSomeInstance, mais nous passerons toujours par la méthode privée miAddAncestor() qui se charge de répercuter la recherche de place libre pour un ancètre dans notre chaine d’ancètres.