Guia de Estilo Solidity

Neste artigo, exploraremos alguns dos elementos essenciais de um guia de estilo do Solidity e forneceremos dicas para escrever um código Solidity limpo, legível e eficiente.

Este Guia de Estilo do Solidity fornece as melhores práticas e recomendações para escrever o código do Solidity.

Manter um guia de estilo ajuda a manter a consistência no layout do código e facilita a leitura. Para redigir contratos com a Solidity, as seguintes práticas recomendadas devem ser seguidas.

Índice-

Layout do código Solidity

Um código bem organizado ajuda você e outros desenvolvedores a entender a estrutura de seus contratos e facilita a localização de seções específicas do código.

O Guia de Estilo do Solidity recomenda organizar seu código em seções para importações, interfaces, contratos e bibliotecas, com cada seção separada por uma única linha em branco.

1. Recuo

O recuo e o espaçamento consistentes tornam seu código mais fácil de ler e entender.

O Guia de estilo do Solidity recomenda o uso de dois espaços para indentação e a adição de um espaço após as vírgulas e ao redor dos operadores .

Example: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// SPDX-License-Identifier: 3.0
pragma solidity ^0.8.0;
contract SolidityTest{
// Here we declare all the functions,variables used in the code using 4 indentation spaces
function get_Bio() public pure returns(string memory){
return "We are learning about Indentation within a contract";
}
// Similar pattern of indentation should be used with variable names
uint number=4;
function get_Number() public view returns(uint){
return number;
}
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<div class="spinner-border" role="status"><span class="sr-only">Loading...</span></div>

Example: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// SPDX-License-Identifier: 3.0
pragma solidity ^0.8.0;
contract SolidityTest{
function age_check(uint user_age) public pure returns(string memory){
if(user_age >= 18){ // As per style guide rule, we leave 4 spaces while declaring a
return "Congratulations !! You are Eligible to cast you vote";
}
else{
return "Sorry !! We do not find you eligible to cast your vote !!";
}
}
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<div class="spinner-border" role="status"><span class="sr-only">Loading...</span></div>

2. Regra das Duas Linhas em Branco

Considera-se uma boa prática deixar dois espaços em branco entre duas definições de contrato.

Example: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// SPDX-License-Identifier: 3.0
pragma solidity ^0.8.0;
contract SolidityTest1{
function get_String() public pure returns(string memory){
return "Hey User !! Please make sure that you leave two lines between two contracts";
}
}
// It is advisable to leave two lines after one contract definition closing brackets
contract SolidityTest2{
uint mrx=52;
function get_number() public view returns(uint){
return mrx;
}
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<div class="spinner-border" role="status"><span class="sr-only">Loading...</span></div>
Aqui, criamos 2 contratos diferentes e os organizamos com base no guia de estilo de solidez. Para melhor entendimento segue o exemplo abaixo:

Example: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// SPDX-License-Identifier: 3.0
pragma solidity ^0.8.0;
contract SolidityTest1{
function Product_Of_Numbers(uint mrx,uint ample) public pure returns(uint){
return mrx*ample;
}
}
// Here we left 2 lines spaces as per solidity style guide //
contract SolidityTest2{
function Devide_Numbers(uint mrx,uint ample) public pure returns(uint){
return mrx/ample;
}
}
contract Mr_Example_Final_Contract is SolidityTest1,SolidityTest2{
SolidityTest1 obj1=new SolidityTest1();
SolidityTest2 obj2=new SolidityTest2();
function call_Contract() public view returns(uint,uint){
uint result1=obj1.Product_Of_Numbers(4,7);
uint result2=obj2.Devide_Numbers(15,3);
return(result1,result2);
}
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<div class="spinner-border" role="status"><span class="sr-only">Loading...</span></div>

3. Regra de uma linha em branco

Recomenda-se usar um espaço de linha entre duas funções. Se a função acabou de ser declarada, não há necessidade de fazer isso. Para melhor entendimento, considere o exemplo abaixo:

Example: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// SPDX-License-Identifier: 3.0
pragma solidity ^0.8.0;
contract SolidityTest1{
function get_String() public pure returns(string memory){
return "Hey User !! Please make sure that you leave one lines space between two functions";
}
// This line is used as one line space between two functions with body
function get_bio() public pure returns(string memory){
return "If function has no body then it is not must to leave one line space";
}
}
abstract contract SolidityTest2 {
function balance() public virtual pure;
function account() public virtual pure;
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<div class="spinner-border" role="status"><span class="sr-only">Loading...</span></div>

Example: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// SPDX-License-Identifier: 3.0
pragma solidity ^0.8.0;
contract SolidityTest{
function Style_Guide() public pure returns(string memory){
return "In Solidity Style Guide, We need one line spacing while declaring a function after function";
}
// This is one line space left between two functions //
function Style_Guide2() public pure returns(string memory){
return "As a perspective of style guide, Leaving one line space between to functions makes it readable and easier to understand the code";
}
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<div class="spinner-border" role="status"><span class="sr-only">Loading...</span></div>

4. Comprimento máximo da linha

Os leitores devem ser capazes de analisar o código facilmente se as linhas não excederem 79 caracteres.

Example: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// SPDX-License-Identifier: 3.0
pragma solidity ^0.8.0;
contract SolidityTest{
function A_Big_Named_Function(
uint mrx1,
uint mrx2,
uint mrx3,
uint mrx4,
uint mrx5,
uint mrx6,
uint mrx7
) public pure returns(uint,uint,uint,uint,uint,uint,uint)
{
return(mrx1,mrx2,mrx3,mrx4,mrx5,mrx6,mrx7);
}
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<div class="spinner-border" role="status"><span class="sr-only">Loading...</span></div>

5. Regras de empacotamento

Recomenda-se que o primeiro argumento seja colocado em uma nova linha sem abrir parênteses. Você deve usar um recuo por argumento. O último elemento deve estar associado a um elemento finalizador.

Example: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// SPDX-License-Identifier: 3.0
pragma solidity ^0.8.0;
contract SolidityTest{
function A_Big_Named_Function(
string memory mrx1,
string memory mrx2,
string memory mrx3,
string memory mrx4,
string memory mrx5,
string memory mrx6,
string memory mrx7
) public pure returns(string memory,string memory,string memory,string memory,string memory,string memory,string memory)
{
return(mrx1,mrx2,mrx3,mrx4,mrx5,mrx6,mrx7);
}
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<div class="spinner-border" role="status"><span class="sr-only">Loading...</span></div>

6. Codificação do Código Fonte

Recomenda-se usar codificações UTF-8 ou ASCII.

7. Importações

Estes devem ser colocados logo após a declaração do pragma no topo do arquivo.

8. Ordem das funções

As funções devem ser agrupadas de acordo com sua visibilidade.

 

// SPDX-License-Identifier: 3.0

pragma solidity ^0.8.0;

contract Mr_Examples {
constructor() public {
// Write the block of code here
}
Function external_Function() external {
// Write the block of code here
}

// External functions
// Write the block of code here

// External view functions
// Write the block of code here

// External pure functions
// Write the block of code here

// Public functions
// Write the block of code here

// Internal functions
// Write the block of code here

// Private functions
// Write the block of code here
}

 

9. Evite espaços em branco extras

É aconselhável evitar espaços extras imediatamente entre parênteses, colchetes ou colchetes.

10. Estruturas de controle

Recomenda-se abrir os colchetes ao mesmo tempo que a declaração. Certifique-se de que eles estejam fechados em sua própria linha para manter o mesmo recuo de antes. Faça uso do espaço com uma chave de abertura.

Example: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// SPDX-License-Identifier: 3.0
pragma solidity ^0.8.0;
contract SolidityTest{
struct My_Site{
uint site_Id;
address site_address;
bool site_is_good;
}
My_Site[] public data;
function add_Data(uint site_Id,address site_address,bool site_is_good) public {
My_Site memory Data = My_Site(site_Id,site_address,site_is_good);
data.push(Data);
}
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<div class="spinner-border" role="status"><span class="sr-only">Loading...</span></div>

11. Tratamento de erros

Lidar com erros em seus contratos inteligentes é importante para garantir que eles funcionem corretamente e com segurança.

O Guia de Estilo do Solidity recomenda o uso de instruções require() para verificar entradas válidas e declarações assert() para verificar erros internos.

Declaração de função

As chaves devem ser usadas de acordo com a regra acima. É sempre uma boa ideia adicionar um rótulo de visibilidade. É necessário colocar o rótulo de visibilidade antes de adicionar qualquer modificador personalizado.

function Built() public Build_House {
selfdestruct(house);
}

Mapeamentos

Certifique-se de evitar espaços em branco ao definir as variáveis ​​de mapeamento.

  • mapping(uint => int) uint_to_int_)mapeamento;
  • mapping(endereço => bool) confirm_Address;
  • mapping(uint => mapping(uint => string)) public info;
  • mapping(uint => mapping(uint => endereço)) data_Address;

Declaração de variável

Não use espaços em branco ao declarar variáveis ​​de array.

uint[] x; está correto enquanto a unidade [] x é considerada uma prática errada;

Declaração de String

Aspas duplas devem ser usadas em vez de aspas simples para declarar uma string.

str = “Sr.Exemplos”; deve ser usado em vez de str = 'Mr.Examples';

Ordem do Layout

Recomenda-se a disposição dos elementos na seguinte ordem:

  • Declarações de pragma
  • Importar declarações
  • Interfaces
  • bibliotecas
  • Contratos

Recomenda-se solicitar interfaces, bibliotecas ou contratos da seguinte forma:

  • Declarações de tipo
  • Variáveis ​​de Estado
  • Eventos
  • Funções
  • Convenções de nomenclatura

Recomenda-se nomear o contrato e a biblioteca de acordo com o estilo CapWords. Por exemplo:

MyContract, Contract_Main etc.

Os nomes dos contratos e bibliotecas devem ser iguais aos nomes dos arquivos.

Se houver vários contratos/bibliotecas em um arquivo, use o nome do contrato/biblioteca principal.

Example: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
// SPDX-License-Identifier: 3.0
// This shows the license version there is no need to modify this
// The pragma version should always be in lower case as initialized below
pragma solidity ^0.8.0;
contract SolidityTest1{ // As per naming conventions the CapWord style should be used for contract names
struct My_Struct{ // The structures should also be initialized with the CapWord style
uint _id; // It is advisable to use mixedCase style while naming variables
string mrx_Name; // It is advisable to use mixedCase style while naming variables
bool is_Solidity_Fun; // It is advisable to use mixedCase style while naming variables
}
My_Struct public ample; // The variable of the struct is initialized here to fetch details to the struct
function fetch_Data() public { // The function name should be in mixedCase
ample=My_Struct(1,"Mr.Examples",true);
}
function get_Id() public view returns(uint){ // The function name should be in mixedCase
return ample._id;
}
function get_Name() public view returns(string memory){ // The function name should be in mixedCase
return ample.mrx_Name;
}
function get_Bool() public view returns(bool){ // The function name should be in mixedCase
return ample.is_Solidity_Fun;
}
}
contract SolidityTest2{ // As per naming conventions the CapWord style should be used for contract names
uint constant age=19; // It is advisable to use mixedCase style while naming variables
function change_Age() public pure returns(uint){ // The function name should be in mixedCase
uint new_Age=13; // It is advisable to use mixedCase style while naming variables
// This returns an error because the value of the constant variable is not changeable
// age=new_Age;
return age;
}
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
<div class="spinner-border" role="status"><span class="sr-only">Loading...</span></div>

Além disso, as seguintes convenções de nomenclatura devem ser lembradas ao nomear variáveis, estruturas e funções em solidity.

Convenções de nomenclatura Visão geral
Nomes de estruturas  Você pode usar o estilo CapWords como My_Struct .
Nomes de eventos  Faça uso de estilos CapWords como Pay_Money e Transfer_Amount .
Nomes de função  Implementar um caso misto como my_Function é uma ideia inteligente.
Variáveis ​​locais e de estado  Recomenda-se usar um estilo misto de letras maiúsculas e minúsculas, como sender_Address e supply .
Constantes  Separe as palavras com todas as letras maiúsculas e sublinhados , como MRX_AMPLE .
Nomes de modificadores  É melhor usar um estilo mixCase como onlyData.
Nomes de enumeração  Recomenda-se usar o estilo CapWords como My_Enum .

 

Conclusão

Para concluir, não é surpresa que seguir um guia de estilo do Solidity seja um dos aspectos mais importantes da escrita de código sustentável e de alta qualidade.

É importante manter um estilo de codificação consistente para garantir que a base de código seja mais fácil de ler e entender.

Isso tornará mais fácil para você e outros desenvolvedores compreender, gerenciar e aprimorar contratos inteligentes.

Nós valorizamos o seu feedback.
+1
0
+1
0
+1
0
+1
0
+1
0
+1
0
+1
0
Assine a nossa newsletter
Digite seu e-mail para receber um resumo semanal de nossos melhores posts. Saber mais!
ícone
Ao assinar, você concorda com nossa política de privacidade e nossos termos de serviço.