LSL Style Guide/ja - Revision history

SakuraNoel Fayray at 17:47, 21 February 2016

2016-02-21T17:47:26Z

← Older revision		Revision as of 10:47, 21 February 2016
Line 9:		Line 9:
	殆どの人々は、プログラミングの独習を始めた当初は、端的に言うと「醜い」プログラムを書きます。それらは大概、以下のような具合です:		殆どの人々は、プログラミングの独習を始めた当初は、端的に言うと「醜い」プログラムを書きます。それらは大概、以下のような具合です:

	<~~lsl~~> default {state_entry(){llSay(0,"Hello World.");}}</~~lsl~~>		<source lang="lsl2"> default {state_entry(){llSay(0,"Hello World.");}}</source>

	しかしながら、このコードは一行が一万語で書かれているプログラムの場合、読み解く（あるいは最後まで解釈する）ことが困難です。それ故、プログラマー達は括弧とインデントについて以下の二つの手法を主に用いて、コードを整形します。		しかしながら、このコードは一行が一万語で書かれているプログラムの場合、読み解く（あるいは最後まで解釈する）ことが困難です。それ故、プログラマー達は括弧とインデントについて以下の二つの手法を主に用いて、コードを整形します。
Line 15:		Line 15:

	手法 1:		手法 1:
	<~~lsl~~>		<source lang="lsl2">
	default {		default {
	state_entry() {		state_entry() {
Line 21:		Line 21:
	}		}
	}		}
	</~~lsl~~>		</source>

	手法 2:		手法 2:
	<~~lsl~~>		<source lang="lsl2">
	default		default
	{		{
Line 32:		Line 32:
	}		}
	}		}
	</~~lsl~~>		</source>

	手法1のスタイルでは行数を節約できますが、手法2のスタイルの方が初心者にとってより読みやすくなります。スクリプタは記述スタイルとして実施することにより、さらに読みやすいコードとなるでしょう。首尾一貫したインデントは、さまざまなスタイルをさらに読みやすくします。手法1におけるインデントは、スコープレベルを表現する鍵となります。		手法1のスタイルでは行数を節約できますが、手法2のスタイルの方が初心者にとってより読みやすくなります。スクリプタは記述スタイルとして実施することにより、さらに読みやすいコードとなるでしょう。首尾一貫したインデントは、さまざまなスタイルをさらに読みやすくします。手法1におけるインデントは、スコープレベルを表現する鍵となります。
Line 41:		Line 41:

	グローバル変数（プログラム全体を通して持ちいられる変数）は最初に小文字のgをつけるべきです。		グローバル変数（プログラム全体を通して持ちいられる変数）は最初に小文字のgをつけるべきです。
	<~~lsl~~>		<source lang="lsl2">
	integer gSelected = 0;		integer gSelected = 0;
	string gMyName = "Please set one";		string gMyName = "Please set one";
	</~~lsl~~>		</source>

	定数として使用する変数は全て大文字を使用します。		定数として使用する変数は全て大文字を使用します。

	<~~lsl~~>		<source lang="lsl2">
	integer CHAT_CHAN = -517265;		integer CHAT_CHAN = -517265;
	key OWNER_KEY = llGetOwner();		key OWNER_KEY = llGetOwner();
	</~~lsl~~>		</source>


	ユーザ定義関数やイベントの中で用いられる引数は、アンダーバー(_)から始めます。		ユーザ定義関数やイベントの中で用いられる引数は、アンダーバー(_)から始めます。
	<~~lsl~~>		<source lang="lsl2">
	listen( integer _channel, string _name, key _id, string _message )		listen( integer _channel, string _name, key _id, string _message )
	{		{
Line 61:		Line 61:
	llOwnerSay("Hello Avatar");		llOwnerSay("Hello Avatar");
	}		}
	</~~lsl~~>		</source>

	==コードの分離==		==コードの分離==

	多くの人達は一行で余りにも沢山の関数を呼び出そうとするでしょう。これはコードを読み難くして、極めてデバッグを困難にします。例として、このようなプログラムを挙げてみます。		多くの人達は一行で余りにも沢山の関数を呼び出そうとするでしょう。これはコードを読み難くして、極めてデバッグを困難にします。例として、このようなプログラムを挙げてみます。
	<~~lsl~~>		<source lang="lsl2">
	list lst;		list lst;
	integer numDigits = 10;		integer numDigits = 10;
Line 80:		Line 80:

	}		}
	</~~lsl~~>		</source>

	先ほどのコードが何を行なっているかあなたに説明できる人は殆どいないでしょうが、以下のコードが何を行なっているかは殆どの人が説明できるでしょう。		先ほどのコードが何を行なっているかあなたに説明できる人は殆どいないでしょうが、以下のコードが何を行なっているかは殆どの人が説明できるでしょう。

	<~~lsl~~>		<source lang="lsl2">
	list lst;		list lst;
	integer numDigits = 10;		integer numDigits = 10;
Line 101:		Line 101:
	}		}
	}		}
	</~~lsl~~>		</source>

	LSL には最適化コンパイラがありません。そのため、より速いコードを実現するには二つのスタイルをバランスよく使う必要があるでしょう。行をまとめてゆく最適化は、コードが動作しバグが無くなってから初めて行なうべきです。不適切な最適化は良くない結果をもたらします。最適化したコードのテストを常に、徹底的に行ないましょう。		LSL には最適化コンパイラがありません。そのため、より速いコードを実現するには二つのスタイルをバランスよく使う必要があるでしょう。行をまとめてゆく最適化は、コードが動作しバグが無くなってから初めて行なうべきです。不適切な最適化は良くない結果をもたらします。最適化したコードのテストを常に、徹底的に行ないましょう。

	<~~lsl~~>		<source lang="lsl2">
	list lst;		list lst;
	integer numDigits = 10;		integer numDigits = 10;
Line 118:		Line 118:
	}		}
	}		}
	</~~lsl~~>		</source>

	==スクリプト構成==		==スクリプト構成==

MasterOf Perl: Make up for dropped sentence

2009-07-06T13:04:33Z

Make up for dropped sentence

← Older revision		Revision as of 06:04, 6 July 2009
Line 103:		Line 103:
	</lsl>		</lsl>

	LSL には最適化コンパイラがありません。そのため、より速いコードを実現するには二つのスタイルをバランスよく使う必要があるでしょう。行をまとめてゆく最適化は、コードが動作しバグが無くなってから初めて行なうべきです。最適化したコードのテストを常に、徹底的に行ないましょう。		LSL には最適化コンパイラがありません。そのため、より速いコードを実現するには二つのスタイルをバランスよく使う必要があるでしょう。行をまとめてゆく最適化は、コードが動作しバグが無くなってから初めて行なうべきです。不適切な最適化は良くない結果をもたらします。最適化したコードのテストを常に、徹底的に行ないましょう。

	<lsl>		<lsl>

MasterOf Perl: Update translation

2009-05-27T13:21:03Z

Update translation

← Older revision		Revision as of 06:21, 27 May 2009
Line 1:		Line 1:
	{{Multi-lang}}{{LSL Header/ja}}{{RightToc}}		{{Multi-lang\|1=LSL Style Guide\|2=/ja}}{{LSL Header/ja}}{{RightToc}}

	~~LSLにおける効率的なプログラミングには、スクリプトを定型と規約に定めるための制約的実行が必要です。~~		LSL の効果的なプログラミングを行なうには、レイアウトと (コーディングの) 慣習をスクリプトへ適用するよう、制作者が規律正しく実践しなければなりません。

	これら、スタイルガイドと呼ばれる集約的要素のガイドラインは、言語コンパイラが必要とするルールほど厳密ではありませんが、それでもなお効率的なメンテナンス性のあるコードを作成するためには必要です。最も効果的なスタイルの様相は、あなたの書くコードに首尾一貫性を持たせることです。		これら、スタイルガイドと呼ばれる集約的要素のガイドラインは、言語コンパイラが必要とするルールほど厳密ではありませんが、それでもなお効率的なメンテナンス性のあるコードを作成するためには必要です。最も効果的なスタイルの様相は、あなたの書くコードに首尾一貫性を持たせることです。
Line 7:		Line 7:
	==一般的なガイドライン==		==一般的なガイドライン==

	~~プログラミングを始めるときに、多くの人々はそれをみて確実に不快感を催すでしょう。彼らは大抵以下のようなものを目にします。~~		殆どの人々は、プログラミングの独習を始めた当初は、端的に言うと「醜い」プログラムを書きます。それらは大概、以下のような具合です:

	default {state_entry(){llSay(0,"Hello World.");}}		<lsl> default {state_entry(){llSay(0,"Hello World.");}}</lsl>

	しかしながら、このコードは一行が一万語で書かれているプログラムの場合、読み解く（あるいは最後まで解釈する）ことが困難です。それ故、プログラマー達は括弧とインデントについて以下の二つの手法を主に用いて、コードを整形します。		しかしながら、このコードは一行が一万語で書かれているプログラムの場合、読み解く（あるいは最後まで解釈する）ことが困難です。それ故、プログラマー達は括弧とインデントについて以下の二つの手法を主に用いて、コードを整形します。
Line 15:		Line 15:

	手法 1:		手法 1:
	<~~pre~~>		<lsl>
	default {		default {
	state_entry() {		state_entry() {
Line 21:		Line 21:
	}		}
	}		}
	</~~pre~~>		</lsl>

	手法 2:		手法 2:
	<~~pre~~>		<lsl>
	default		default
	{		{
Line 32:		Line 32:
	}		}
	}		}
	</~~pre~~>		</lsl>

	手法1のスタイルでは行数を節約できますが、手法2のスタイルの方が初心者にとってより読みやすくなります。スクリプタは記述スタイルとして実施することにより、さらに読みやすいコードとなるでしょう。首尾一貫したインデントは、さまざまなスタイルをさらに読みやすくします。手法1におけるインデントは、スコープレベルでの要素を表す鍵です。		手法1のスタイルでは行数を節約できますが、手法2のスタイルの方が初心者にとってより読みやすくなります。スクリプタは記述スタイルとして実施することにより、さらに読みやすいコードとなるでしょう。首尾一貫したインデントは、さまざまなスタイルをさらに読みやすくします。手法1におけるインデントは、スコープレベルを表現する鍵となります。

	==命名規則==		==命名規則==
Line 41:		Line 41:

	グローバル変数（プログラム全体を通して持ちいられる変数）は最初に小文字のgをつけるべきです。		グローバル変数（プログラム全体を通して持ちいられる変数）は最初に小文字のgをつけるべきです。
	<~~pre~~>		<lsl>
	integer gSelected = 0;		integer gSelected = 0;
	string gMyName = "Please set one";		string gMyName = "Please set one";
	</~~pre~~>		</lsl>

	定数として使用する変数は全て大文字を使用します。		定数として使用する変数は全て大文字を使用します。

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


	ユーザ定義関数やイベントの中で用いられる引数は、アンダーバー(_)から始めます。		ユーザ定義関数やイベントの中で用いられる引数は、アンダーバー(_)から始めます。
	<~~pre~~>		<lsl>
	listen( integer _channel, string _name, key _id, string _message )		listen( integer _channel, string _name, key _id, string _message )
	{		{
Line 61:		Line 61:
	llOwnerSay("Hello Avatar");		llOwnerSay("Hello Avatar");
	}		}
	</~~pre~~>		</lsl>

	==コードの分離==		==コードの分離==

	多くの人達は一行で余りにも沢山の関数を呼び出そうとするでしょう。これはコードを読み難くして、極めてデバッグを困難にします。例として、このようなプログラムを挙げてみます。		多くの人達は一行で余りにも沢山の関数を呼び出そうとするでしょう。これはコードを読み難くして、極めてデバッグを困難にします。例として、このようなプログラムを挙げてみます。
	<~~pre~~>		<lsl>
	list lst;		list lst;
	integer numDigits = 10;		integer numDigits = 10;
Line 80:		Line 80:

	}		}
	</~~pre~~>		</lsl>

	いまここに、簡潔になる方法をとった、まったく同じ処理のコードがあります。誰かが、先ほどのコードが一体何を行っているのか、あなたに説明することで困難になっている間に、多くの人達はこのコードを教えるでしょう。		先ほどのコードが何を行なっているかあなたに説明できる人は殆どいないでしょうが、以下のコードが何を行なっているかは殆どの人が説明できるでしょう。

	<~~pre~~>		<lsl>
	list lst;		list lst;
	integer numDigits = 10;		integer numDigits = 10;
Line 101:		Line 101:
	}		}
	}		}
	</~~pre~~>		</lsl>

	LSLは最適化コンパイラではありません。これは、二つのスタイルがさらに軽快なコードにすることにはバランスが必要となる理由でしょう。行を混ぜ合わせる最適化は、後々コードの動作をバグでいっぱいにするでしょう。間違った最適化は、よくない結果を招きいれます。常に十分に最適化されたコードを試みましょう。		LSL には最適化コンパイラがありません。そのため、より速いコードを実現するには二つのスタイルをバランスよく使う必要があるでしょう。行をまとめてゆく最適化は、コードが動作しバグが無くなってから初めて行なうべきです。最適化したコードのテストを常に、徹底的に行ないましょう。

	<~~pre~~>		<lsl>
	list lst;		list lst;
	integer numDigits = 10;		integer numDigits = 10;
Line 118:		Line 118:
	}		}
	}		}
	</~~pre~~>		</lsl>

	==スクリプト構成==		==スクリプト構成==
Line 125:		Line 125:

	#定義された変数を用いる([[LSL_Variables/ja\|LSL_Variables]]を参照)		#定義された変数を用いる([[LSL_Variables/ja\|LSL_Variables]]を参照)
	#定義された関数を用いる([[~~User-defined_functions~~]]を参照)		#定義された関数を用いる([[ユーザ定義関数]]を参照)
	#[[default/ja\|default]] State ([[State/ja\|state]]を参照)		#[[default/ja\|default]] State ([[State/ja\|state]]を参照)
	#定義されたステートを用いる		#定義されたステートを用いる

Asuka Neely: /* スクリプト構成 */ changed to link translated page

2008-06-30T17:29:11Z

スクリプト構成: changed to link translated page

← Older revision		Revision as of 10:29, 30 June 2008
Line 124:		Line 124:
	LSLスクリプトは、関数、ステートメント、イベントハンドラ、ステートの要素によって構成されています。LSLコンパイラはスクリプトに正確な構造化を強制します。		LSLスクリプトは、関数、ステートメント、イベントハンドラ、ステートの要素によって構成されています。LSLコンパイラはスクリプトに正確な構造化を強制します。

	#定義された変数を用いる([[LSL_Variables]]を参照)		#定義された変数を用いる([[LSL_Variables/ja\|LSL_Variables]]を参照)
	#定義された関数を用いる([[User-defined_functions]]を参照)		#定義された関数を用いる([[User-defined_functions]]を参照)
	#[[default]] State ([[State]]を参照)		#[[default/ja\|default]] State ([[State/ja\|state]]を参照)
	#定義されたステートを用いる		#定義されたステートを用いる

Hidenori Glushenko: いくつか訳文調整

2007-12-26T02:15:50Z

いくつか訳文調整

← Older revision		Revision as of 19:15, 25 December 2007
Line 11:		Line 11:
	default {state_entry(){llSay(0,"Hello World.");}}		default {state_entry(){llSay(0,"Hello World.");}}

	しかしながら、このコードは一行が一万語で書かれているプログラムの場合、読み解く（あるいは最後まで解釈する）ことが困難です。それ故、プログラマー達は主に括弧とインデントという二つの手法を用います。		しかしながら、このコードは一行が一万語で書かれているプログラムの場合、読み解く（あるいは最後まで解釈する）ことが困難です。それ故、プログラマー達は括弧とインデントについて以下の二つの手法を主に用いて、コードを整形します。


	~~手法一~~:		手法 1:
	<pre>		<pre>
	default {		default {
Line 23:		Line 23:
	</pre>		</pre>

	~~手法二~~:		手法 2:
	<pre>		<pre>
	default		default
Line 34:		Line 34:
	</pre>		</pre>

	手法一あるいは手法二の位置づけスペースは初心者にとってより読みやすくなります。スクリプタは記述スタイルとして実施することにより、さらに読みやすいコードとなるでしょう。首尾一貫したインデントは、さまざまなスタイルをさらに読みやすくします。手法一におけるインデントは、スコープレベルでの要素を表す鍵です。		手法1のスタイルでは行数を節約できますが、手法2のスタイルの方が初心者にとってより読みやすくなります。スクリプタは記述スタイルとして実施することにより、さらに読みやすいコードとなるでしょう。首尾一貫したインデントは、さまざまなスタイルをさらに読みやすくします。手法1におけるインデントは、スコープレベルでの要素を表す鍵です。

	==命名規則==		==命名規則==
Line 46:		Line 46:
	</pre>		</pre>

	~~固有変数は全て大文字を用いるべきです。~~		定数として使用する変数は全て大文字を使用します。

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


	ユーザ定義関数やイベントの中で用いられる引数は、アンダーバー(_)~~から始めるべきです。~~		ユーザ定義関数やイベントの中で用いられる引数は、アンダーバー(_)から始めます。
	<pre>		<pre>
	listen( integer _channel, string _name, key _id, string _message )		listen( integer _channel, string _name, key _id, string _message )

Asuka Neely: /* 命名規則 */

2007-12-25T08:23:48Z

命名規則

← Older revision		Revision as of 01:23, 25 December 2007
Line 46:		Line 46:
	</pre>		</pre>

	~~固有変数は全て大文字を用いるべきです。例:~~		固有変数は全て大文字を用いるべきです。

	<pre>		<pre>

Asuka Neely at 08:22, 25 December 2007

2007-12-25T08:22:16Z

← Older revision		Revision as of 01:22, 25 December 2007
Line 1:		Line 1:
	{{Multi-lang}}{{LSL Header/ja}}{{RightToc}}		{{Multi-lang}}{{LSL Header/ja}}{{RightToc}}

	~~'''現在翻訳作業中です...'''（これは翻訳作業者が、作業中であることを明示するために挿入した一文です。）~~

	LSLにおける効率的なプログラミングには、スクリプトを定型と規約に定めるための制約的実行が必要です。		LSLにおける効率的なプログラミングには、スクリプトを定型と規約に定めるための制約的実行が必要です。

Asuka Neely at 08:20, 25 December 2007

2007-12-25T08:20:04Z

← Older revision		Revision as of 01:20, 25 December 2007
Line 3:		Line 3:
	'''現在翻訳作業中です...'''（これは翻訳作業者が、作業中であることを明示するために挿入した一文です。）		'''現在翻訳作業中です...'''（これは翻訳作業者が、作業中であることを明示するために挿入した一文です。）

	~~Effective programming in LSL requires that developers use a disciplined practice for applying formatting and convention to their scripts.~~		LSLにおける効率的なプログラミングには、スクリプトを定型と規約に定めるための制約的実行が必要です。

	These guidelines, referred to collectively as a Style Guide, are not as rigid as the rules required by the language compiler but nonetheless are critical to creating maintainable code. The most critical aspect of a style is that you apply it consistently to the code you write.		これら、スタイルガイドと呼ばれる集約的要素のガイドラインは、言語コンパイラが必要とするルールほど厳密ではありませんが、それでもなお効率的なメンテナンス性のあるコードを作成するためには必要です。最も効果的なスタイルの様相は、あなたの書くコードに首尾一貫性を持たせることです。

	==~~General Guidelines~~==		==一般的なガイドライン==

	~~Most people, when they start programming on their own, will have programs that are UGLY to look at; to put it nicely. They usually look like the following:~~		プログラミングを始めるときに、多くの人々はそれをみて確実に不快感を催すでしょう。彼らは大抵以下のようなものを目にします。

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

	~~However, that code is impossible to read (or at least to ''follow'') when one is writing a ten thousand word program. Therefore, programmers have two main methods as to bracketing and indenting.~~		しかしながら、このコードは一行が一万語で書かれているプログラムの場合、読み解く（あるいは最後まで解釈する）ことが困難です。それ故、プログラマー達は主に括弧とインデントという二つの手法を用います。


	~~Method One~~:		手法一:
	<pre>		<pre>
	default {		default {
Line 25:		Line 25:
	</pre>		</pre>

	~~Method Two~~:		手法二:
	<pre>		<pre>
	default		default
Line 36:		Line 36:
	</pre>		</pre>

	Method One conserves space, however Method Two is easier to read for the beginner. Once a scripter is the practice of using a particular style, reading code in that style will be easier. Consistent indenting makes reading both styles easier. In Method One indenting is the key indicating factor of levels of scope.		手法一あるいは手法二の位置づけスペースは初心者にとってより読みやすくなります。スクリプタは記述スタイルとして実施することにより、さらに読みやすいコードとなるでしょう。首尾一貫したインデントは、さまざまなスタイルをさらに読みやすくします。手法一におけるインデントは、スコープレベルでの要素を表す鍵です。

	==~~Naming Conventions~~==		==命名規則==

	~~There are many naming conventions in~~ Second ~~Life. Only the most used ones will be listed below.~~		Second Lifeには、多くの命名規則が存在します。ただ、最も使われるものは次に並んだものでしょう。


	~~Global Variables (variables used through out the entire program) should begin with a lowercase g. For Example:~~

			グローバル変数（プログラム全体を通して持ちいられる変数）は最初に小文字のgをつけるべきです。
	<pre>		<pre>
	integer gSelected = 0;		integer gSelected = 0;
Line 50:		Line 48:
	</pre>		</pre>

			固有変数は全て大文字を用いるべきです。例:
	~~Variable Constants should be in ALL CAPS. For Example~~:

	<pre>		<pre>
Line 59:		Line 56:


	~~Arguments used within a user defined function or an [[event]] should start with an underline~~ (_)~~. For Example:~~		ユーザ定義関数やイベントの中で用いられる引数は、アンダーバー(_)から始めるべきです。

	<pre>		<pre>
	listen( integer _channel, string _name, key _id, string _message )		listen( integer _channel, string _name, key _id, string _message )
Line 69:		Line 65:
	</pre>		</pre>

	==~~Separating Code~~==		==コードの分離==
	~~Many people will start out doing many, many function calls on one line. This makes the code hard to read, and almost impossible to debug. The following is an example of one such program:~~
			多くの人達は一行で余りにも沢山の関数を呼び出そうとするでしょう。これはコードを読み難くして、極めてデバッグを困難にします。例として、このようなプログラムを挙げてみます。
	<pre>		<pre>
	list lst;		list lst;
Line 87:		Line 84:
	</pre>		</pre>

	~~Now here is the code, with the exact same features, in a simpler way. While hardly anyone could tell you what the above code did, almost everyone can tell you what the below code does.~~		いまここに、簡潔になる方法をとった、まったく同じ処理のコードがあります。誰かが、先ほどのコードが一体何を行っているのか、あなたに説明することで困難になっている間に、多くの人達はこのコードを教えるでしょう。

	<pre>		<pre>
Line 108:		Line 105:
	</pre>		</pre>

	LSL lacks an optimizing compiler. For this reason it may be necessary to balance the two style to get faster code. Line combination optimization should only be done after the code is working & bug free. Improper optimization can lead to wrong results. Always test optimized code thoroughly.		LSLは最適化コンパイラではありません。これは、二つのスタイルがさらに軽快なコードにすることにはバランスが必要となる理由でしょう。行を混ぜ合わせる最適化は、後々コードの動作をバグでいっぱいにするでしょう。間違った最適化は、よくない結果を招きいれます。常に十分に最適化されたコードを試みましょう。

	<pre>		<pre>
Line 125:		Line 122:
	</pre>		</pre>

	==~~Script Structure~~==		==スクリプト構成==
	~~LSL scripts are comprised of expressions, functions, statements, event handlers and states. The LSL compiler mandates a certain structure to scripts:~~
			LSLスクリプトは、関数、ステートメント、イベントハンドラ、ステートの要素によって構成されています。LSLコンパイラはスクリプトに正確な構造化を強制します。

	#~~User Defined Variables~~ (~~see~~ [[LSL_Variables]])		#定義された変数を用いる([[LSL_Variables]]を参照)
	#~~User Defined Functions~~ (~~see~~ [[User-defined_functions]])		#定義された関数を用いる([[User-defined_functions]]を参照)
	#[[default]] State (~~see~~ [[State]])		#[[default]] State ([[State]]を参照)
	#~~User Defined States~~		#定義されたステートを用いる

	==~~Editor~~==		==エディタ==

	~~There are many 3rd party editors with LSL syntax files.~~		多くのサードパーティ製エディタとLSL構文ファイルがあります。その他の情報は[[LSL Alternate Editors]]を参照してください。
	~~See~~ [[LSL Alternate Editors]] ~~for more information.~~

Asuka Neely at 05:38, 25 December 2007

2007-12-25T05:38:31Z

← Older revision		Revision as of 22:38, 24 December 2007
Line 1:		Line 1:
	{{Multi-lang}}{{LSL Header/ja}}{{RightToc}}		{{Multi-lang}}{{LSL Header/ja}}{{RightToc}}

	'''現在翻訳作業中です...'''		'''現在翻訳作業中です...'''（これは翻訳作業者が、作業中であることを明示するために挿入した一文です。）

	Effective programming in LSL requires that developers use a disciplined practice for applying formatting and convention to their scripts.		Effective programming in LSL requires that developers use a disciplined practice for applying formatting and convention to their scripts.

Asuka Neely at 05:37, 25 December 2007

2007-12-25T05:37:16Z

← Older revision		Revision as of 22:37, 24 December 2007
Line 1:		Line 1:
	{{Multi-lang}}{{LSL Header/ja}}{{RightToc}}		{{Multi-lang}}{{LSL Header/ja}}{{RightToc}}

			'''現在翻訳作業中です...'''

	Effective programming in LSL requires that developers use a disciplined practice for applying formatting and convention to their scripts.		Effective programming in LSL requires that developers use a disciplined practice for applying formatting and convention to their scripts.