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.
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:
Example:
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:
Example:
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:
Example:
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:
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:
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:
11. Tratamento de erros
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:
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.