LSL Style Guide/fr - Revision history

Strife Onizuka at 00:28, 25 October 2008

2008-10-25T00:28:53Z

← Older revision		Revision as of 17:28, 24 October 2008
Line 1:		Line 1:
	{{Multi-lang}}{{LSL Header}}{{RightToc}}		{{Multi-lang}}{{LSL Header{{#var:lang}}}}{{RightToc}}

	Comme tout langage, LSL demande la pratique d'une discipline pour appliquer aux scripts les formats et conventions appropriés.		Comme tout langage, LSL demande la pratique d'une discipline pour appliquer aux scripts les formats et conventions appropriés.

Catherine Pfeffer: Proofread

2007-12-02T15:40:41Z

Proofread

← Older revision		Revision as of 08:40, 2 December 2007
Line 3:		Line 3:
	Comme tout langage, LSL demande la pratique d'une discipline pour appliquer aux scripts les formats et conventions appropriés.		Comme tout langage, LSL demande la pratique d'une discipline pour appliquer aux scripts les formats et conventions appropriés.

	Ces règles, réunies sous le nom de Guide de ~~Style~~, ne sont pas aussi rigides que celles imposées par le compilateur mais sont néanmoins critiques pour créer du code lisible et maintenable. La chose la plus importante en matère de style est de l'appliquer avec constance.		Ces règles, réunies sous le nom de Guide de style, ne sont pas aussi rigides que celles imposées par le compilateur mais sont néanmoins critiques pour créer du code lisible et maintenable. La chose la plus importante en matère de style est de l'appliquer avec constance.


	==Conventions ~~Générales~~==		==Conventions générales==

	La plupart des gens, lorsqu'ils débutent en programmation, écrivent un programme MOCHE pour parler gentiment. Ça ressemble en général à ceci:		La plupart des gens, lorsqu'ils débutent en programmation, écrivent un programme MOCHE pour parler gentiment. Ça ressemble en général à ceci:
Line 14:		Line 14:
	Hélas, ce code devient impossible à lire (du moins à 'suivre') quand il s'agit d'un programme de 10000 mots. Pour y remédier, les programmeurs utilisent deux méthodes pour structurer/indenter:		Hélas, ce code devient impossible à lire (du moins à 'suivre') quand il s'agit d'un programme de 10000 mots. Pour y remédier, les programmeurs utilisent deux méthodes pour structurer/indenter:

	~~Méthode Une~~:		Première méthode :
	<pre>		<pre>
	default {		default {
Line 23:		Line 23:
	</pre>		</pre>

	~~Méthode Deux~~:		Seconde méthode :
	<pre>		<pre>
	default		default
Line 34:		Line 34:
	</pre>		</pre>

	La ~~Méthode Une~~ économise l'espace, toutefois la ~~Méthode Deux~~ est plus facile à lire pour le débutant. Lorsqu'un programmeur a choisi un style, la lecture de son code s'avère plus facile. Des indentations uniformes rendent les deux styles plus facile à lire. Dans ~~le Méthode Un~~, l'indentation est le marque essentielle de l'imbrication des blocs.		La première méthode économise l'espace, toutefois la deuxième méthode est plus facile à lire pour le débutant. Lorsqu'un programmeur a choisi un style, la lecture de son code s'avère plus facile. Des indentations uniformes rendent les deux styles plus facile à lire. Dans la première méthode, l'indentation est le marque essentielle de l'imbrication des blocs.

	==Conventions de ~~Nommage~~==		==Conventions de nommage==

	Les conventions de nommage sont nombreuses dans Second Life. Seules les plus ~~usitées~~ seront citées ici.		Les conventions de nommage sont nombreuses dans Second Life. Seules les plus utilisées seront citées ici.

	Les variables globales (accessibles en tout point du programme) commencent par un 'g' minuscule. Exemple:		Les variables globales (accessibles en tout point du programme) commencent par un 'g' minuscule. Exemple :

	<pre>		<pre>
Line 47:		Line 47:
	</pre>		</pre>

	Les constantes sont EN MAJUSCULES. Exemple:		Les constantes sont EN MAJUSCULES. Exemple :

	<pre>		<pre>
Line 54:		Line 54:
	</pre>		</pre>

	Les arguments d'une fonction ou d'un ~~évènement (~~[[event]]) commencent par un blanc souligné (_). Exemple:		Les arguments d'une fonction ou d'un [[event\|évènement]] commencent par un blanc souligné (_). Exemple :

	<pre>		<pre>
Line 66:		Line 66:
	==Lisibilité==		==Lisibilité==

	Beaucoup de débutants alignent beaucoup, beaucoup d'instructions sur une seule ligne. Cela rend le code peu lisible et pratiquement impossible à déboguer. Voici un mauvais exemple:		Beaucoup de débutants alignent beaucoup, beaucoup d'instructions sur une seule ligne. Cela rend le code peu lisible et pratiquement impossible à déboguer. Voici un mauvais exemple :

	<pre>		<pre>
Line 84:		Line 84:
	</pre>		</pre>

	Maintenant voici un code avec exactement la même fonctionnalité mais plus simple. Alors qu'on a du mal à dire ce que fait le code ci-dessus, celui-ci coule presque de source (jeu de mot voulu:).		Maintenant voici un code avec exactement la même fonctionnalité mais plus simple. Alors qu'on a du mal à dire ce que fait le code ci-dessus, celui-ci coule presque de source (jeu de mot voulu).

	<pre>		<pre>
Line 123:		Line 123:

	==Structure==		==Structure==
	Un script LSL se compose d'expressions, fonctions, instructions, gestionnaires d'évènements (event handlers) et états (states). Le compilateur LSL impose une certaine structure sur les scripts:		Un script LSL se compose d'expressions, de fonctions, d'instructions, de gestionnaires d'évènements (event handlers) et d'états (states). Le compilateur LSL impose une certaine structure sur les scripts :

	#Variables définies par le programmeur (cf. [[LSL_Variables]])		#Variables définies par le programmeur (cf. [[LSL_Variables]])
Line 133:		Line 133:

	Il existe plusieurs éditeurs alternatifs gérant la syntaxe de LSL avec les fichiers de définitions appropriés.		Il existe plusieurs éditeurs alternatifs gérant la syntaxe de LSL avec les fichiers de définitions appropriés.
	Cf. [[LSL Alternate Editors]] ~~for more information~~.		Cf. [[LSL Alternate Editors\|éditeurs alternatifs]] pour plus d'informations.

Jeff Kelley: first translation

2007-12-02T15:19:48Z

first translation

New page

{{Multi-lang}}{{LSL Header}}{{RightToc}}

Comme tout langage, LSL demande la pratique d'une discipline pour appliquer aux scripts les formats et conventions appropriés.

Ces règles, réunies sous le nom de Guide de Style, ne sont pas aussi rigides que celles imposées par le compilateur mais sont néanmoins critiques pour créer du code lisible et maintenable. La chose la plus importante en matère de style est de l'appliquer avec constance.

==Conventions Générales==

La plupart des gens, lorsqu'ils débutent en programmation, écrivent un programme MOCHE pour parler gentiment. Ça ressemble en général à ceci:

default {state_entry(){llSay(0,"Hello World.");}}

Hélas, ce code devient impossible à lire (du moins à 'suivre') quand il s'agit d'un programme de 10000 mots. Pour y remédier, les programmeurs utilisent deux méthodes pour structurer/indenter:

Méthode Une:
<pre>
default {
state_entry() {
llSay(0, "Hello World.");
}
}
</pre>

Méthode Deux:
<pre>
default
{
state_entry()
{
llSay(0, "Hello World.");
}
}
</pre>

La Méthode Une économise l'espace, toutefois la Méthode Deux est plus facile à lire pour le débutant. Lorsqu'un programmeur a choisi un style, la lecture de son code s'avère plus facile. Des indentations uniformes rendent les deux styles plus facile à lire. Dans le Méthode Un, l'indentation est le marque essentielle de l'imbrication des blocs.

==Conventions de Nommage==

Les conventions de nommage sont nombreuses dans Second Life. Seules les plus usitées seront citées ici.

Les variables globales (accessibles en tout point du programme) commencent par un 'g' minuscule. Exemple:

<pre>
integer gSelected = 0;
string gMyName = "Please set one";
</pre>

Les constantes sont EN MAJUSCULES. Exemple:

<pre>
integer CHAT_CHAN = -517265;
key OWNER_KEY = llGetOwner();
</pre>

Les arguments d'une fonction ou d'un évènement ([[event]]) commencent par un blanc souligné (_). Exemple:

<pre>
listen( integer _channel, string _name, key _id, string _message )
{
if ( _channel == 1 || _id == llGetOwner() )
llOwnerSay("Hello Avatar");
}
</pre>

==Lisibilité==

Beaucoup de débutants alignent beaucoup, beaucoup d'instructions sur une seule ligne. Cela rend le code peu lisible et pratiquement impossible à déboguer. Voici un mauvais exemple:

<pre>
list lst;
integer numDigits = 10;
default {

touch_start(integer n) {
integer i = 0;
integer index = llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1))]);
if (!~llListFindList(lst, [llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1))]))
lst += llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1));
llOwnerSay(llList2CSV(lst));
}

}
</pre>

Maintenant voici un code avec exactement la même fonctionnalité mais plus simple. Alors qu'on a du mal à dire ce que fait le code ci-dessus, celui-ci coule presque de source (jeu de mot voulu:).

<pre>
list lst;
integer numDigits = 10;

default {
touch_start(integer n) {
integer i = 0;
string name = llKey2Name(llDetectedKey(i));
list nameAsList = llParseString2List(name, [" "], []);
string firstName = llList2String(nameAsList, 0);
string startPart = llToLower(llGetSubString(firstName, 0, numDigits - 1));
integer index = llListFindList(lst, (list)startPart);
if (!~index)
lst += startPart;
llOwnerSay(llList2CSV(lst));
}
}
</pre>

Le compilateur de LSL n'est pas optimiseur. Il peut donc être nécessaire de sacrifier au style pour produire du code plus rapide. Les optimisation par regroupement en une ligne seront faites seulement une fois que le code est fonctionnel et testé. Une optimisation trop précoce peut conduire à un faux résultat. Testez toujours soigneusement vos optimisations.

<pre>
list lst;
integer numDigits = 10;

default {
touch_start(integer n) {
integer i = 0;
string startPart = llToLower(llGetSubString(llList2String(llParseString2List(llKey2Name(llDetectedKey(i)), [" "], []), 0), 0, numDigits - 1));
if (!~llListFindList(lst, (list)startPart))
lst += startPart;
llOwnerSay(llList2CSV(lst));
}
}
</pre>

==Structure==
Un script LSL se compose d'expressions, fonctions, instructions, gestionnaires d'évènements (event handlers) et états (states). Le compilateur LSL impose une certaine structure sur les scripts:

#Variables définies par le programmeur (cf. [[LSL_Variables]])
#Fonctions définies par le programmeur (cf. [[User-defined_functions]])
#État par défaut (cf. [[State]])
#États définis par le programmeur

==Éditeurs==

Il existe plusieurs éditeurs alternatifs gérant la syntaxe de LSL avec les fichiers de définitions appropriés.
Cf. [[LSL Alternate Editors]] for more information.