摘要:命名規范避免使用小寫的,大寫的,大寫的應該避免在命名中多帶帶出現,因為很容易產生混淆。對于函數,始終以小寫字母開頭,構造函數除外。
本文首發于深入淺出區塊鏈社區
原文鏈接:智能合約最佳實踐之Solidity編碼規范原文已更新,請讀者前往原文閱讀
每一門語言都有其相應的編碼規范, Solidity 也一樣, 下面官方推薦的規范及我的總結,供大家參考,希望可以幫助大家寫出更好規范的智能合約。
命名規范 避免使用小寫的l,大寫的I,大寫的O 應該避免在命名中多帶帶出現,因為很容易產生混淆。
合約、庫、事件、枚舉及結構體命名合約、庫、事件及結構體命名應該使用單詞首字母大寫的方式,這個方式也稱為:帕斯卡命名法或大駝峰式命名法,比如:SimpleToken, SmartBank, CertificateHashRepository,Player。
函數、參數、變量及修飾器函數、參數、變量及修飾器應該使用首單詞小寫后面單詞大寫的方式,這個方式也稱為:(?。劮迨矫?,是一種混合大小寫的方式,如:
函數名應該如:getBalance,transfer,verifyOwner,addMember。
參數和變量應該如:initialSupply,senderAddress,account,isPreSale。
修飾器應該如:onlyAfter,onlyOwner。
代碼格式相關 縮進使用空格(spaces)而不是Tab, 縮進應該是4個空格
空行合約之間應該有空行,例如:
contract A { ... } contract B { ... } contract C { ... }
而不是使用:
contract A { ... } contract B { ... } contract C { ... }
函數之間應該有空行,例如:
contract A { function spam() public { ... } function ham() public { ... } }
沒有實現的話,空行可以省去,如:
contract A { function spam() public; function ham() public; }
而不是:
contract A { function spam() public { ... } function ham() public { ... } }左括號應該跟定義在一行
定義包括合約定義、函數定義、庫定義、結構體定義等等,例如推薦使用:
contract Coin { struct Bank { address owner; uint balance; } }
而不是:
contract Coin { struct Bank { address owner; uint balance; } }左括號應該跟條件控制在一行
在使用if, else, while, for 時,推薦的寫法是:
if (...) { ... } for (...) { ... }
而不是:
if (...) { ... } while(...){ } for (...) { ...;}
如果控制語句內只有一行,括號可省略,如:
if (x < 10) x += 1;
但像下面一個語句有多方就不能省略,如:
if (x < 10) someArray.push(Coin({ name: "spam", value: 42 }));表達式內的空格
一個單行的表達里,在小括號、中括號、大括號里應該避免不必要的空格,例如推薦使用:
spam(ham[1], Coin({name: "ham"}));
而不是:
spam( ham[ 1 ], Coin( { name: "ham" } ) );
有一種例外是,結尾的括號跟在結束的分號后面, 應該加一個空格,如下面的方式也是推薦的:
function singleLine() public { spam(); }
分號;前不應該有空格,例如推薦使用:
function spam(uint i, Coin coin) public;
而不是:
function spam(uint i , Coin coin) public ;
不要為對齊添加不必要的空格,例如推薦使用:
x = 1; y = 2; long_variable = 3;
而不是:
x = 1; y = 2; long_variable = 3;
回退函數不應該有空格,例如推薦使用:
function() public { ... }
而不是:
function () public { ... }控制每一行長度
每行不應該太長,最好在79(或99)個字符以內,函數的參數應該是多帶帶的行,且只有一個縮進,例如推薦的方式是:
thisFunctionCallIsReallyLong( longArgument1, longArgument2, longArgument3 );
而不是:
thisFunctionCallIsReallyLong(longArgument1, longArgument2, longArgument3 ); thisFunctionCallIsReallyLong(longArgument1, longArgument2, longArgument3 ); thisFunctionCallIsReallyLong( longArgument1, longArgument2, longArgument3 ); thisFunctionCallIsReallyLong( longArgument1, longArgument2, longArgument3 ); thisFunctionCallIsReallyLong( longArgument1, longArgument2, longArgument3);
對應的賦值語句應該是這樣寫:
thisIsALongNestedMapping[being][set][to_some_value] = someFunction( argument1, argument2, argument3, argument4 );
而不是:
thisIsALongNestedMapping[being][set][to_some_value] = someFunction(argument1, argument2, argument3, argument4);
事件定義也應該遵循同樣的原則,例如應該使用:
event LongAndLotsOfArgs( adress sender, adress recipient, uint256 publicKey, uint256 amount, bytes32[] options ); LongAndLotsOfArgs( sender, recipient, publicKey, amount, options );
而不是:
event LongAndLotsOfArgs(adress sender, adress recipient, uint256 publicKey, uint256 amount, bytes32[] options); LongAndLotsOfArgs(sender, recipient, publicKey, amount, options);文件編碼格式
推薦使用utf-8 及 ASCII 編碼
引入文件應該在最上方建議使用:
import "owned"; contract A { ... } contract B is owned { ... }
而不是:
contract A { ... } import "owned"; contract B is owned { ... }函數編寫規范 函數的順序
在編寫函數的時候,應該讓大家容易找到構造函數,回退函數,官方推薦的的函數順序是:
構造函數
回退函數 (如果有)
外部函數(external)
公有函數(public)
內部函數(internal)
私有函數(private)
同一類函數時,constant函數放在后面, 例如推薦方式為:
contract A { // 構造函數 function A() public { ... } // 回退函數 function() public { ... } // 外部函數 // ... // 帶有constant 外部函數 // ... // 公有函數 // ... // 內部函數 // ... // 私有函數 // ... }
而不是下面的函數順序:
contract A { // 外部函數 // ... // 公有函數 // ... // 內部函數 // ... function A() public { ... } function() public { ... } // 私有函數 // ... }明確函數的可見性
所有的函數(包括構造函數)應該在定義的時候明確函數的可見性,例如應該使用:
function explicitlyPublic(uint val) public { doSomething(); }
而不是
function implicitlyPublic(uint val) { doSomething(); }可見性應該在修飾符前面
函數的可見性應該寫在自定義的函數修飾符前面,例如:
function kill() public onlyowner { selfdestruct(owner); }
而不是
function kill() onlyowner public { selfdestruct(owner); }區分函數和事件
為了防止函數和事件(Event)產生混淆,聲明一個事件使用大寫并加入前綴(可使用LOG)。對于函數, 始終以小寫字母開頭,構造函數除外。
// 不建議 event Transfer() {} function transfer() {} // 建議 event LogTransfer() {} function transfer() external {}常量
常量應該使用全大寫及下劃線分割大詞的方式,如:MAX_BLOCKS,TOKEN_NAME, CONTRACT_VERSION。
參考視頻我們也推出了目前市面上最全的視頻教程:深入詳解以太坊智能合約語言Solidity
目前我們也在招募體驗師,可以點擊鏈接了解。
Solidity style-guide
? 深入淺出區塊鏈 - 系統學習區塊鏈,打造最好的區塊鏈技術博客。
? 我的知識星球為各位解答區塊鏈技術問題,歡迎加入討論。
? 關注公眾號“深入淺出區塊鏈技術”第一時間獲取區塊鏈技術信息。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/24070.html
摘要:本文首發于深入淺出區塊鏈社區原文鏈接智能合約語言教程系列函數類型原文已更新,請讀者前往原文閱讀教程系列第三篇函數類型介紹。函數類型函數也是一種類型,且屬于值類型。但以此相反,合約中函數本身默認是的,僅僅是當作類型名使用時默認是的。 本文首發于深入淺出區塊鏈社區原文鏈接:智能合約語言Solidity教程系列3 - 函數類型原文已更新,請讀者前往原文閱讀 Solidity 教程系列第三篇 ...
摘要:圍繞以太坊的開發生態是目前相對最成熟的,比如有開發框架,有智能合約在線集成開發環境,還有專設的開發者問答頻道。 showImg(https://segmentfault.com/img/bVbaJOL?w=1200&h=514); 張泉靈說,時代拋棄我們的時候連聲再見都不會說,馬云說對于新興事物,絕大多數人是看不見、看不起、看不懂、來不及。自從學完 Coursera 上的 Crypto...
摘要:圍繞以太坊的開發生態是目前相對最成熟的,比如有開發框架,有智能合約在線集成開發環境,還有專設的開發者問答頻道。 showImg(https://segmentfault.com/img/bVbaJOL?w=1200&h=514); 張泉靈說,時代拋棄我們的時候連聲再見都不會說,馬云說對于新興事物,絕大多數人是看不見、看不起、看不懂、來不及。自從學完 Coursera 上的 Crypto...
閱讀 2954·2021-11-11 16:55
閱讀 515·2021-09-27 13:36
閱讀 1073·2021-09-22 15:35
閱讀 2908·2019-08-30 12:46
閱讀 3125·2019-08-26 17:02
閱讀 1826·2019-08-26 11:56
閱讀 1295·2019-08-26 11:47
閱讀 423·2019-08-23 17:01