스마트 컨트랙트 (5-1) | Solidity(솔리디티) 레이아웃

@Solidity https://en.bitcoinwiki.org/wiki/Solidity

 

1. Solidity Language

1-1. 특성

- 절차적 언어 ( VS 함수형 언어)

- 정적 타입 언어 (컴파일 시 타입 결정. 오류 시 컴파일 에러)

- 변수 이름의 대소문자 구분

- 객체 지향 언어

- 확장자 : sol

 

 

 

 

2. LayOut

2-1. pragma

파일 최상단에 위치, 컴파일러의 특정 기능을 활성화하는 데에 사용

Pragmas

The pragma keyword is used to enable certain compiler features or checks. A pragma directive is always local to a source file, so you have to add the pragma to all your files if you want to enable it in your whole project. If you import another file, the pragma from that file does not automatically apply to the importing file.

1. Version Pragma
Source files can (and should) be annotated with a version pragma to reject compilation with future compiler versions that might introduce incompatible changes. We try to keep these to an absolute minimum and introduce them in a way that changes in semantics also require changes in the syntax, but this is not always possible. Because of this, it is always a good idea to read through the changelog at least for releases that contain breaking changes. These releases always have versions of the form 0.x.0 or x.0.0.

2. ABI Coder Pragma
By using pragma abicoder v1 or pragma abicoder v2 
you can select between the two implementations of the ABI encoder and decoder.
The new ABI coder (v2) is able to encode and decode arbitrarily nested arrays and structs. It might produce less optimal code and has not received as much testing as the old encoder, but is considered non-experimental as of Solidity 0.6.0. You still have to explicitly activate it using pragma abicoder v2;. Since it will be activated by default starting from Solidity 0.8.0, there is the option to select the old coder using pragma abicoder v1;.

3. Experimental Pragma
The second pragma is the experimental pragma. It can be used to enable features of the compiler or language that are not yet enabled by default. The following experimental pragmas are currently supported:
(1) ABIEncoderV2: Because the ABI coder v2 is not considered experimental anymore, it can be selected via pragma abicoder v2 (please see above) since Solidity 0.7.4.
(2) SMTChecker: This component has to be enabled when the Solidity compiler is built and therefore it is not available in all Solidity binaries. The build instructions explain how to activate this option. It is activated for the Ubuntu PPA releases in most versions, but not for the Docker images, Windows binaries or the statically-built Linux binaries. It can be activated for solc-js via the smtCallback if you have an SMT solver installed locally and run solc-js via node (not via the browser).If you use pragma experimental SMTChecker;, then you get additional safety warnings which are obtained by querying an SMT solver. The component does not yet support all features of the Solidity language and likely outputs many warnings. In case it reports unsupported features, the analysis may not be fully sound.

https://docs.soliditylang.org/en/v0.8.13/layout-of-source-files.html 

The version pragma is used as follows: pragma solidity ^0.5.2;

A source file with the line above does not compile with a compiler earlier than version 0.5.2,
and it also does not work on a compiler starting from version 0.6.0
(this second condition is added by using ^).

Because there will be no breaking changes until version 0.6.0, you can be sure that your code compiles the way you intended. The exact version of the compiler is not fixed, so that bugfix releases are still possible.

https://docs.soliditylang.org/en/v0.8.13/layout-of-source-files.html 

 

 

 

2-2. Comments, 주석

Comments
Single-line comments (//) and multi-line comments (/*...*/) are possible.

https://docs.soliditylang.org/en/v0.8.13/layout-of-source-files.html#comments

// This is a single-line comment.

/*
This is a
multi-line comment.
*/

 

2-2-1. NatSpec Comments : 문서화를 돕는 주석

Additionally, there is another type of comment called a NatSpec comment, which is detailed in the style guide. They are written with a triple slash (///) or a double asterisk block (/** ... */) and they should be used directly above function declarations or statements.

https://docs.soliditylang.org/en/v0.8.13/layout-of-source-files.html#comments 

[NatSpec]

Solidity contracts can also contain NatSpec comments. They are written with a triple slash (///) or a double asterisk block (/** ... */) and they should be used directly above function declarations or statements. (...) It is recommended that Solidity contracts are fully annotated using NatSpec for all public interfaces (everything in the ABI).

https://docs.soliditylang.org/en/v0.8.13/style-guide.html#style-guide-natspec

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

/// @author The Solidity Team
/// @title A simple storage example
contract SimpleStorage {
    uint storedData;

    /// Store `x`.
    /// @param x the new value to store
    /// @dev stores the number in the state variable `storedData`
    function set(uint x) public {
        storedData = x;
    }

    /// Return the stored value.
    /// @dev retrieves the value of the state variable `storedData`
    /// @return the stored value
    function get() public view returns (uint) {
        return storedData;
    }
}

[NatSpec Format]

Solidity contracts can use a special form of comments to provide rich documentation for functions, return variables and more. This special form is named the Ethereum Natural Language Specification Format (NatSpec).

NatSpec was inspired by Doxygen. While it uses Doxygen-style comments and tags, there is no intention to keep strict compatibility with Doxygen. Please carefully examine the supported tags listed below.

NatSpec includes the formatting for comments that the smart contract author will use, and which are understood by the Solidity compiler. Also detailed below is output of the Solidity compiler, which extracts these comments into a machine-readable format. NatSpec may also include annotations used by third-party tools. These are most likely accomplished via the @custom:<name> tag, and a good use case is analysis and verification tools.

https://docs.soliditylang.org/en/v0.8.13/natspec-format.html#natspec 

NatSpec Format — Solidity 0.8.13 documentation

 

 

 

2-3. import

Importing other Source Files

Syntax and Semantics
Solidity supports import statements to help modularise your code that are similar to those available in JavaScript (from ES6 on). However, Solidity does not support the concept of a default export.
At a global level, you can use import statements of the following form:

import "filename";

The filename part is called an import path. This statement imports all global symbols from “filename” (and symbols imported there) into the current global scope (different than in ES6 but backwards-compatible for Solidity). This form is not recommended for use, because it unpredictably pollutes the namespace. If you add new top-level items inside “filename”, they automatically appear in all files that import like this from “filename”. It is better to import specific symbols explicitly. The following example creates a new global symbol symbolName whose members are all the global symbols from "filename":

import * as symbolName from "filename";

which results in all global symbols being available in the format symbolName.symbol.
A variant of this syntax that is not part of ES6, but possibly useful is:
import "filename" as symbolName;
which is equivalent to import * as symbolName from "filename";. If there is a naming collision, you can rename symbols while importing. For example, the code below creates new global symbols alias and symbol2 which reference symbol1 and symbol2 from inside "filename", respectively.

import {symbol1 as alias, symbol2} from "filename";
("filename" can be fully explicit or implicit)

Import Paths
In order to be able to support reproducible builds on all platforms, the Solidity compiler has to abstract away the details of the filesystem where source files are stored. For this reason import paths do not refer directly to files in the host filesystem. Instead the compiler maintains an internal database (virtual filesystem or VFS for short) where each source unit is assigned a unique source unit name which is an opaque and unstructured identifier. The import path specified in an import statement is translated into a source unit name and used to find the corresponding source unit in this database.
Using the Standard JSON API it is possible to directly provide the names and content of all the source files as a part of the compiler input. In this case source unit names are truly arbitrary. If, however, you want the compiler to automatically find and load source code into the VFS, your source unit names need to be structured in a way that makes it possible for an import callback to locate them. When using the command-line compiler the default import callback supports only loading source code from the host filesystem, which means that your source unit names must be paths. Some environments provide custom callbacks that are more versatile. For example the Remix IDE provides one that lets you import files from HTTP, IPFS and Swarm URLs or refer directly to packages in NPM registry. For a complete description of the virtual filesystem and the path resolution logic used by the compiler see Path Resolution.

https://docs.soliditylang.org/en/v0.8.13/layout-of-source-files.html#importing-other-source-files 

 

 

 

 

 

FOR KOREAN USERS. 한국어 문서도 확인 가능하다.

https://solidity-kr.readthedocs.io/ko