Difference between revisions of "LSL Style Guide/ja"

From Second Life Wiki
Jump to navigation Jump to search
m (New page: {{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. The...)
 
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Multi-lang}}{{LSL Header/ja}}{{RightToc}}
{{Multi-lang|1=LSL Style Guide|2=/ja}}{{LSL Header/ja}}{{RightToc}}


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.");}}
<source lang="lsl2">    default {state_entry(){llSay(0,"Hello World.");}}</source>


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:
手法 1:
<pre>
<source lang="lsl2">
     default {
     default {
         state_entry() {
         state_entry() {
Line 21: Line 21:
         }
         }
     }
     }
</pre>
</source>


Method Two:
手法 2:
<pre>
<source lang="lsl2">
     default
     default
     {
     {
Line 32: Line 32:
         }
         }
     }
     }
</pre>
</source>


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


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


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


 
グローバル変数（プログラム全体を通して持ちいられる変数）は最初に小文字のgをつけるべきです。
Global Variables (variables used through out the entire program) should begin with a lowercase g. For Example:
<source lang="lsl2">
 
<pre>
     integer gSelected = 0;
     integer gSelected = 0;
     string  gMyName = "Please set one";
     string  gMyName = "Please set one";
</pre>
</source>
 


Variable Constants should be in ALL CAPS. For Example:
定数として使用する変数は全て大文字を使用します。


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


Arguments used within a user defined function or an [[event]] should start with an underline (_). For Example:


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


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


}
}
</pre>
</source>


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>
<source lang="lsl2">
list lst;
list lst;
integer numDigits = 10;
integer numDigits = 10;
Line 104: Line 101:
     }
     }
}
}
</pre>
</source>


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>
<source lang="lsl2">
list lst;
list lst;
integer numDigits = 10;
integer numDigits = 10;
Line 121: Line 118:
     }
     }
}
}
</pre>
</source>
 
==スクリプト構成==


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


#User Defined Variables  (see [[LSL_Variables]])
#定義された変数を用いる([[LSL_Variables/ja|LSL_Variables]]を参照)
#User Defined Functions (see [[User-defined_functions]])
#定義された関数を用いる([[ユーザ定義関数]]を参照)
#[[default]] State  (see [[State]])
#[[default/ja|default]] State  ([[State/ja|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.

Latest revision as of 09:47, 21 February 2016

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

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

一般的なガイドライン

殆どの人々は、プログラミングの独習を始めた当初は、端的に言うと「醜い」プログラムを書きます。それらは大概、以下のような具合です: 

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

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


手法 1: 

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

手法 2: 

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

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

命名規則

Second Lifeには、多くの命名規則が存在します。ただ、最も使われるものは次に並んだものでしょう。

グローバル変数（プログラム全体を通して持ちいられる変数）は最初に小文字のgをつけるべきです。 

    integer gSelected = 0;
    string  gMyName = "Please set one";

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

    integer CHAT_CHAN = -517265;
    key OWNER_KEY = llGetOwner();


ユーザ定義関数やイベントの中で用いられる引数は、アンダーバー(_)から始めます。 

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

コードの分離

多くの人達は一行で余りにも沢山の関数を呼び出そうとするでしょう。これはコードを読み難くして、極めてデバッグを困難にします。例として、このようなプログラムを挙げてみます。 

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));
   }

}

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

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));
    }
}

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

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));
    }
}

スクリプト構成

LSLスクリプトは、関数、ステートメント、イベントハンドラ、ステートの要素によって構成されています。LSLコンパイラはスクリプトに正確な構造化を強制します。

  1. 定義された変数を用いる(LSL_Variablesを参照)
  2. 定義された関数を用いる(ユーザ定義関数を参照)
  3. default State (stateを参照)
  4. 定義されたステートを用いる

エディタ

多くのサードパーティ製エディタとLSL構文ファイルがあります。その他の情報はLSL Alternate Editorsを参照してください。

Retrieved from "https://wiki.secondlife.com/w/index.php?title=LSL_Style_Guide/ja&oldid=1199196"