8 编码规范与工程实践

2019-11-24  本文已影响0人  智能合约大师兄

8.1 项目结构

在进行实际项目开发过程中会涉及不同的开发人员以及多个不同的库和合约,如果没有统一的项目组织结构以及编码规范,在后续进行系统功能升级和扩展的时候会导致各种各样未知的问题。因此在进行工程项目开发时,在实际动手编码前要解决的第一个问题就是开发团队关于项目的组织结构和编码规范达成一致。本章介绍的关于项目组织结构和编码规范不是强制要求而只是一种建议,在实际开发中可以以此为模板再根据业务需要进行修订或扩展。如果团队已有现成的编码规范则以团队现有的编码规范为主,本章介绍的编码规范作为补充。

实际项目中一般都会利用已有的项目代码或第三方库,而不是从零开始自己开发,而且业务逻辑本身也会划分为不同的模块,一种建议方式是先依据业务逻辑进行模块的自然划分并每个模块一个独立文件夹,公共的库或者合约独立文件夹,测试合约和用例也独立文件夹,然后根目录下只保留主业务逻辑的入口合约,如下所示:


image.png

doc文件夹存放项目相关文档,public存放公用的库和基础合约供外部使用或继承,test文件夹存放测试相关合约,其他文件夹为业务模块相关文件夹,ProjectName.sol为项目主入口合约。

虽然remix作为智能合约的开发、测试和部署来说是神器,但对其工程化项目开发的支持目前还比较弱,因此不直接支持上面的目录结构划分,但可以通过其提供的外部导入以及github来变通实现。也就是在github上建立上面的模块目录结构,reimx中编写项目主合约和测试主合约,对其他库和合约的引用通过remix提供的外部导入方式来在线引用。

关于github这个程序员宝库的使用请读者自行查询相关资料,此处示范一个导入github现成库的一个范例。实例代码中通过外部引入方式引用zeppelin合约库中的一个基础合约作为基类并进行功能扩展实现数据的限制访问,导入其它资源库中的合约方法一样,实例代码如下:

import "https://github.com/OpenZeppelin/zeppelin-solidity/contracts/ownership/Ownable.sol";

contract ImportTest is Ownable {
    uint public val;

    function setVal(uint nnew) public onlyOwner {
        val = nnew;
    }
}

代码中需要注意的是外部导入语句是一行只是由于排版问题看起来是两行。通过外部在线引入的方式可以使用众多的第三方功能库进而加快编码进度和提高安全性。但如果项目不复杂只需要几个合约就能实现所需功能则可以直接在本地进行项目的扁平化编码,然后通过本地引用的方式直接用,示意代码如下:

//MyOwn.sol
contract MyOwn {
    address admin;
    modifier onlyAdmin() {
        require(msg.sender == admin);
        _;
    }
    function MyOwn() public {
        admin = msg.sender;
    }
}
//ImportTest2.sol
import "./MyOwn.sol";
contract ImportTest2 is MyOwn {
    uint public val;
    function setVal(uint nnew) public onlyAdmin {
        val = nnew;
    }
}

remix中直接建立2个独立合约文件并通过本地导入的方式进行引用。笔者认为remix还需要在工程模块化开发方面进一步完善,来支持多目录结构以及多人同时在线协作开发就更完美了。

8.2 文件结构

上一篇下一篇

猜你喜欢

热点阅读