solidityプログラミング仕様
17911 ワード
プログラミング仕様
概要
このガイドはSolidityを記述するためのコード仕様を提供するために使用されます.このガイドは、後続のニーズに応じて変更が進み、新しいより適切な仕様が追加され、古い不適切な仕様が廃棄される可能性があります.
もちろん、多くのプロジェクトには独自の符号化仕様がある可能性がありますが、競合がある場合は、プロジェクトの符号化仕様を参照してください.
このガイドの構造および仕様の提案の多くはpythonのpep 8符号化仕様から来ている.
このガイドは、マニュアルの要求に完全に従ってsolidity符号化を行う必要があるというのではなく、pep 8の理念と似ている全体的な一貫性の要求を提供します(訳注:pep 8の理念は、強制的な一貫性は非常に愚かな行為であり、pep 8を参照).
このガイドは、符号化スタイルの一貫性を提供するために、一貫性という理念が重要であり、プロジェクトでは符号化スタイルの一貫性がより重要であり、同じ関数またはモジュールではスタイルの一貫性が最も重要である.最も重要なのは、いつ一貫性を維持する必要があるか、いつ一貫性を維持する必要がないかを知ることです.このマニュアルが必ずしも適用されるとは限らない場合があります.自分のニーズに合わせて比較する必要があります.下の例を参考にして、どちらがあなたにとって最適かを決めることができます.
コードレイアウト
インデント
行ごとに4つのスペースでインデント
tabまたはスペース
スペースは優先的にインデントされます
tabとスペースの混在を禁止
リターン
2つの契約の間に2行の空行を増やす
仕様の方法:
規範化されていない方法:
契約内部の関数間にはリターンが必要です.関数宣言と関数実装が一緒であれば、2つのリターンが必要です.
仕様の方法:
規範化されていない方法:
ソースファイルエンコーディング方式
優先UTF-8またはASCII符号化
導入
一般的にコード開始宣言
仕様の方法:
規範化されていない方法:
式のスペースの使用方法
次のシーンではスペースの使用を避けます.括弧、中括弧、括弧の後にスペース を使用しないでください.
Yes仕様の方式:spam(ham[1],Coin({name:「ham」)
No規範化されていない方式:spam(ham[1],Coin({name:"ham"});カンマとセミコロンを使用する前に、スペース を使用しないでください.
Yes仕様の方式:function spam(uint i,Coin coin);
No規範化されていない方式:function spam(uint i,Coin coin);賦値子前後複数のスペースを避ける 仕様の方法:
規範化されていない方法:
せいぎょこうぞう
契約、ライブラリ.関数、構造体のかっこの使用方法:左かっこと同じ行を宣言 右かっこと左かっこは、同じインデント位置を維持することを宣言します. 左かっこ後は に戻る
仕様の方法:
規範化されていない方法:
以上の提案はif,else,while,forにも同様に適用される.
また、if、while、for条件文の間には空行が必要です
仕様の方法:
規範化されていない方法:
制御構造の内部では、単一の文のみで括弧を使用する必要はありません.
仕様の方法:
規範化されていない方法:
if文にelseまたはelse if文が含まれている場合、else文は新しい行になります.elseとelse ifの内部仕様はifと同じです.
仕様の方法:
規範化されていない方法:
関数宣言
短い関数宣言では、関数体の左かっこと関数名を同じ行に配置することを推奨します.
右かっこと関数宣言は同じインデントを維持します.
左かっこと関数名の間にスペースを追加します.
仕様の方法:
規範化されていない方法:
デフォルトの修飾子は、他のカスタム修飾子の前に置く必要があります.
仕様の方法:
規範化されていない方法:
パラメータの多い関数宣言では、すべてのパラメータを行単位で表示し、同じインデントを維持します.関数宣言の右かっこと関数体の左かっこは同じ行に配置され、関数宣言と同じインデントが保持されます.
仕様の方法:
規範化されていない方法:
関数に複数の修飾子が含まれている場合は、修飾子を行ごとにインデントして表示する必要があります.関数体の左かっこも行を分けます.
仕様の方法:
規範化されていない方法:
コンストラクション関数としてパラメータを必要とする派生契約の場合、関数の宣言が長すぎたり、読みにくい場合は、コンストラクション関数にベースクラスが含まれるコンストラクション関数の行を独立して表示することをお勧めします.
仕様の方法:
規範化されていない方法:
関数宣言のプログラミング仕様は主に可読性を向上させるために使用され、本ガイドはすべてのプログラミング仕様を網羅することはできません.関連しない場所では、プログラム猿は自分の主観的能動性を発揮することができます.
完了するマッピング
変数宣言
配列変数宣言では、タイプと配列のカッコにスペースを付けることはできません.
仕様の方法:uint[]x;規範化されていない方法:uint[]x;
その他の推奨事項賦値演算子の両側には、 のスペースが必要です.
仕様の方法:
規範化されていない方法:優先度を表示するには、優先度演算子と低優先度演算子の間にスペースが必要です.これも、複雑な宣言の可読性を向上させるためです.演算子の両側のスペースの数は一致している必要があります.
仕様の方法:
規範化されていない方法:
ネーミング仕様
ネーミング仕様は強力で広く使用されており、異なるネーミング仕様を使用して異なる情報を伝えることができます.
以下の提案は、コードの可読性を向上させるために使用されるので、ルールではなく、関連コードのより良い解釈を支援するために規範化される.
最後に,符号化スタイルの一貫性が最も重要である.
ネーミング方式
混同を防止するために、以下のネーミングは、異なるネーミング方法を説明(説明)するために使用される. b(単一小文字) B(単一大文字) 小文字 下線付き小文字 大文字 下線付き大文字 CapWords仕様(頭文字大) ハイブリッド方式(CapitalizedWordsとの違いはアルファベット小文字!) 下線のある頭文字の大文字(pythonでは推奨されません) に注意
CapWords仕様(イニシャル大文字)の略語を使用する場合、HTTPServerErrorはHttpServerErrorよりもよく理解できるように、略語はすべて大文字です.
回避されたネーミング方法 l-Lowercase letter el小文字のl O-Uppercase letter oh大文字o I-Uppercase letter eye大文字i 文字「l」(小文字el(読み方、以下同))、「O」(大文字oh)、または「I」(大文字eye)を単一文字の変数名として使用しないでください.一部のフォントでは、これらの文字は数字1と0と区別できません.「l」を使うときは「L」で代用してみましょう.
契約およびライブラリの名前
契約はCapWords仕様で命名する必要があります(頭文字は大文字).
≪イベント|Events|ldap≫
イベントはCapWords仕様で命名する必要があります(頭文字は大文字).
関数の名前付け
関数名の大文字と小文字のブレンド
関数パラメータの名前付け
カスタム構造体のライブラリ関数を定義する場合は、構造体の名前に自己解釈機能が必要です.
ローカル変数の名前付け
大文字と小文字のブレンド
定数ネーミング
定数はすべて大文字で下線で区切られます.
修飾子の名前付け
機能修飾子は小文字で下線で区切られます.
衝突を避ける単一下線末尾 この仕様は、組み込みまたは保持名と競合する場合に推奨されます.
共通の推奨事項
完了待ち
変換元:https://github.com/twq0076262/solidity-zh/edit/master/style-guide.md
イーサー坊DAppの開発を効率的に学びたい場合は、集智網が提供する最も人気のあるオンラインインタラクティブチュートリアルにアクセスできます.ブロックチェーン初心者向けイーサ坊DApp実戦入門チュートリアル ブロックチェーン+IPFS+Node.js+MongoDB+Express去中心化以太坊電子商取引応用開発実戦 他にもこのエーテル坊ブログにアクセスできます.
概要
このガイドはSolidityを記述するためのコード仕様を提供するために使用されます.このガイドは、後続のニーズに応じて変更が進み、新しいより適切な仕様が追加され、古い不適切な仕様が廃棄される可能性があります.
もちろん、多くのプロジェクトには独自の符号化仕様がある可能性がありますが、競合がある場合は、プロジェクトの符号化仕様を参照してください.
このガイドの構造および仕様の提案の多くはpythonのpep 8符号化仕様から来ている.
このガイドは、マニュアルの要求に完全に従ってsolidity符号化を行う必要があるというのではなく、pep 8の理念と似ている全体的な一貫性の要求を提供します(訳注:pep 8の理念は、強制的な一貫性は非常に愚かな行為であり、pep 8を参照).
このガイドは、符号化スタイルの一貫性を提供するために、一貫性という理念が重要であり、プロジェクトでは符号化スタイルの一貫性がより重要であり、同じ関数またはモジュールではスタイルの一貫性が最も重要である.最も重要なのは、いつ一貫性を維持する必要があるか、いつ一貫性を維持する必要がないかを知ることです.このマニュアルが必ずしも適用されるとは限らない場合があります.自分のニーズに合わせて比較する必要があります.下の例を参考にして、どちらがあなたにとって最適かを決めることができます.
コードレイアウト
インデント
行ごとに4つのスペースでインデント
tabまたはスペース
スペースは優先的にインデントされます
tabとスペースの混在を禁止
リターン
2つの契約の間に2行の空行を増やす
仕様の方法:
contract A {
...}
contract B {
...}
contract C {
...}
規範化されていない方法:
contract A {
...}contract B {
...}
contract C {
...}
契約内部の関数間にはリターンが必要です.関数宣言と関数実装が一緒であれば、2つのリターンが必要です.
仕様の方法:
contract A {
function spam();
function ham();
}
contract B is A {
function spam() {
...
}
function ham() {
...
}
}
規範化されていない方法:
contract A {
function spam() {
...
}
function ham() {
...
}}
ソースファイルエンコーディング方式
優先UTF-8またはASCII符号化
導入
一般的にコード開始宣言
仕様の方法:
import "owned";
contract A {
...}
contract B is owned {
...}
規範化されていない方法:
contract A {
...}
import "owned";
contract B is owned {
...}
式のスペースの使用方法
次のシーンではスペースの使用を避けます.
Yes仕様の方式:spam(ham[1],Coin({name:「ham」)
No規範化されていない方式:spam(ham[1],Coin({name:"ham"});
Yes仕様の方式:function spam(uint i,Coin coin);
No規範化されていない方式:function spam(uint i,Coin coin);
x = 1;
y = 2;
long_variable = 3;
規範化されていない方法:
x = 1;
y = 2;
long_variable = 3;
せいぎょこうぞう
契約、ライブラリ.関数、構造体のかっこの使用方法:
仕様の方法:
contract Coin {
struct Bank {
address owner;
uint balance;
}
}
規範化されていない方法:
contract Coin
{
struct Bank {
address owner;
uint balance;
}
}
以上の提案はif,else,while,forにも同様に適用される.
また、if、while、for条件文の間には空行が必要です
仕様の方法:
if (...) {
...
}
for (...) {
...
}
規範化されていない方法:
if (...)
{
...
}
while(...)
{
}
for (...)
{
...;
}
制御構造の内部では、単一の文のみで括弧を使用する必要はありません.
仕様の方法:
if (x < 10)
x += 1;
規範化されていない方法:
if (x < 10)
someArray.push(Coin({
name: 'spam',
value: 42
}));
if文にelseまたはelse if文が含まれている場合、else文は新しい行になります.elseとelse ifの内部仕様はifと同じです.
仕様の方法:
if (x < 3) {
x += 1;
}
else {
x -= 1;
}
if (x < 3)
x += 1;
else
x -= 1;
規範化されていない方法:
if (x < 3) {
x += 1;}
else {
x -= 1;}
関数宣言
短い関数宣言では、関数体の左かっこと関数名を同じ行に配置することを推奨します.
右かっこと関数宣言は同じインデントを維持します.
左かっこと関数名の間にスペースを追加します.
仕様の方法:
function increment(uint x) returns (uint) {
return x + 1;
}
function increment(uint x) public onlyowner returns (uint) {
return x + 1;
}
規範化されていない方法:
function increment(uint x) returns (uint)
{
return x + 1;
}
function increment(uint x) returns (uint)
{
return x + 1;
}
function increment(uint x) returns (uint)
{
return x + 1;
}
function increment(uint x) returns (uint)
{
return x + 1;
}
デフォルトの修飾子は、他のカスタム修飾子の前に置く必要があります.
仕様の方法:
function kill() public onlyowner {
selfdestruct(owner);
}
規範化されていない方法:
function kill() onlyowner public {
selfdestruct(owner);
}
パラメータの多い関数宣言では、すべてのパラメータを行単位で表示し、同じインデントを維持します.関数宣言の右かっこと関数体の左かっこは同じ行に配置され、関数宣言と同じインデントが保持されます.
仕様の方法:
function thisFunctionHasLotsOfArguments(
address a,
address b,
address c,
address d,
address e,
address f,
) {
do_something;
}
規範化されていない方法:
function thisFunctionHasLotsOfArguments(address a, address b, address c,
address d, address e, address f) {
do_something;
}
function thisFunctionHasLotsOfArguments(address a,
address b,
address c,
address d,
address e,
address f) {
do_something;
}
function thisFunctionHasLotsOfArguments(
address a,
address b,
address c,
address d,
address e,
address f) {
do_something;
}
関数に複数の修飾子が含まれている場合は、修飾子を行ごとにインデントして表示する必要があります.関数体の左かっこも行を分けます.
仕様の方法:
function thisFunctionNameIsReallyLong(address x, address y, address z)
public
onlyowner
priced
returns (address)
{
do_something;
}
function thisFunctionNameIsReallyLong(
address x,
address y,
address z,)
public
onlyowner
priced
returns (address)
{
do_something;
}
規範化されていない方法:
function thisFunctionNameIsReallyLong(address x, address y, address z)
public
onlyowner
priced
returns (address) {
do_something;
}
function thisFunctionNameIsReallyLong(address x, address y, address z)
public onlyowner priced returns (address){
do_something;
}
function thisFunctionNameIsReallyLong(address x, address y, address z)
public
onlyowner
priced
returns (address) {
do_something;
}
コンストラクション関数としてパラメータを必要とする派生契約の場合、関数の宣言が長すぎたり、読みにくい場合は、コンストラクション関数にベースクラスが含まれるコンストラクション関数の行を独立して表示することをお勧めします.
仕様の方法:
contract A is B, C, D {
function A(uint param1, uint param2, uint param3, uint param4, uint param5)
B(param1)
C(param2, param3)
D(param4)
{
// do something with param5
}
}
規範化されていない方法:
contract A is B, C, D {
function A(uint param1, uint param2, uint param3, uint param4, uint param5)
B(param1)
C(param2, param3)
D(param4)
{
// do something with param5
}
}
contract A is B, C, D {
function A(uint param1, uint param2, uint param3, uint param4, uint param5)
B(param1)
C(param2, param3)
D(param4) {
// do something with param5
}
}
関数宣言のプログラミング仕様は主に可読性を向上させるために使用され、本ガイドはすべてのプログラミング仕様を網羅することはできません.関連しない場所では、プログラム猿は自分の主観的能動性を発揮することができます.
完了するマッピング
変数宣言
配列変数宣言では、タイプと配列のカッコにスペースを付けることはできません.
仕様の方法:uint[]x;規範化されていない方法:uint[]x;
その他の推奨事項
仕様の方法:
x = 3;x = 100 / 10;x += 3 + 4;x |= y && z;
規範化されていない方法:
x=3;x = 100/10;x += 3+4;x |= y&&z;
仕様の方法:
x = 2**3 + 5;x = 2***y + 3*z;x = (a+b) * (a-**b);
規範化されていない方法:
x = 2** 3 + 5;x = y+z;x +=1;
ネーミング仕様
ネーミング仕様は強力で広く使用されており、異なるネーミング仕様を使用して異なる情報を伝えることができます.
以下の提案は、コードの可読性を向上させるために使用されるので、ルールではなく、関連コードのより良い解釈を支援するために規範化される.
最後に,符号化スタイルの一貫性が最も重要である.
ネーミング方式
混同を防止するために、以下のネーミングは、異なるネーミング方法を説明(説明)するために使用される.
CapWords仕様(イニシャル大文字)の略語を使用する場合、HTTPServerErrorはHttpServerErrorよりもよく理解できるように、略語はすべて大文字です.
回避されたネーミング方法
契約およびライブラリの名前
契約はCapWords仕様で命名する必要があります(頭文字は大文字).
≪イベント|Events|ldap≫
イベントはCapWords仕様で命名する必要があります(頭文字は大文字).
関数の名前付け
関数名の大文字と小文字のブレンド
関数パラメータの名前付け
カスタム構造体のライブラリ関数を定義する場合は、構造体の名前に自己解釈機能が必要です.
ローカル変数の名前付け
大文字と小文字のブレンド
定数ネーミング
定数はすべて大文字で下線で区切られます.
修飾子の名前付け
機能修飾子は小文字で下線で区切られます.
衝突を避ける
共通の推奨事項
完了待ち
変換元:https://github.com/twq0076262/solidity-zh/edit/master/style-guide.md
イーサー坊DAppの開発を効率的に学びたい場合は、集智網が提供する最も人気のあるオンラインインタラクティブチュートリアルにアクセスできます.