Solidez - Guía de estilo

La guía de estilo ayuda a mantener el diseño del código coherente y hacer que el código sea más legible. A continuación se presentan las mejores prácticas que se siguen al escribir contratos con Solidity.

Diseño de código

  • Indentation- Utilice 4 espacios en lugar de tabulación para mantener el nivel de sangría. Evite mezclar espacios con pestañas.

  • Two Blank Lines Rule - Utilice 2 líneas en blanco entre dos definiciones de contrato.

pragma solidity ^0.5.0;

contract LedgerBalance {
   //...
}
contract Updater {
   //...
}

  • One Blank Line Rule- Utilice 1 línea en blanco entre dos funciones. En caso de declaración única, no es necesario tener líneas en blanco.

pragma solidity ^0.5.0;

contract A {
   function balance() public pure;
   function account() public pure;
}
contract B is A {
   function balance() public pure {
      // ...
   }
   function account() public pure {
      // ...
   }
}

  • Maximum Line Length - Una sola línea no debe cruzar 79 caracteres para que los lectores puedan analizar fácilmente el código.

  • Wrapping rules- El primer argumento debe estar en una nueva línea sin abrir paréntesis. Utilice sangría única por argumento. Elemento de terminación); debería ser el último.

function_with_a_long_name(
   longArgument1,
   longArgument2,
   longArgument3
);
variable = function_with_a_long_name(
   longArgument1,
   longArgument2,
   longArgument3
);
event multipleArguments(
   address sender,
   address recipient,
   uint256 publicKey,
   uint256 amount,
   bytes32[] options
);
MultipleArguments(
   sender,
   recipient,
   publicKey,
   amount,
   options
);

  • Source Code Encoding - Preferiblemente se utilizará codificación UTF-8 o ASCII.

  • Imports - Las declaraciones de importación deben colocarse en la parte superior del archivo, justo después de la declaración pragma.

  • Order of Functions - Las funciones deben agruparse según su visibilidad.

pragma solidity ^0.5.0;

contract A {
   constructor() public {
      // ...
   }
   function() external {
      // ...
   }

   // External functions
   // ...

   // External view functions
   // ...

   // External pure functions 
   // ...

   // Public functions
   // ...

   // Internal functions
   // ...

   // Private functions
   // ...
}

  • Avoid extra whitespaces - Evite los espacios en blanco inmediatamente entre paréntesis, corchetes o llaves.

  • Control structures- Las llaves deben abrirse en la misma línea que la declaración. Cierre en su propia línea manteniendo la misma sangría. Utilice un espacio con abrazadera de apertura.

pragma solidity ^0.5.0;

contract Coin {
   struct Bank {
      address owner;
      uint balance;
   }
}
if (x < 3) {
   x += 1;
} else if (x > 7) {
   x -= 1;
} else {
   x = 5;
}
if (x < 3)
   x += 1;
else
   x -= 1;

  • Function Declaration- Utilice la regla anterior para llaves. Agregue siempre una etiqueta de visibilidad. La etiqueta de visibilidad debe ir primero antes de cualquier modificador personalizado.

function kill() public onlyowner {
   selfdestruct(owner);
}

  • Mappings - Evite los espacios en blanco al declarar variables de mapeo.

mapping(uint => uint) map;
mapping(address => bool) registeredAddresses;
mapping(uint => mapping(bool => Data[])) public data;
mapping(uint => mapping(uint => s)) data;

  • Variable declaration - Evite los espacios en blanco al declarar variables de matriz.

uint[] x;  // not unit [] x;

  • String declaration - Utilice comillas dobles para declarar una cadena en lugar de comillas simples.

str = "foo";
str = "Hamlet says, 'To be or not to be...'";

Orden de diseño

Los elementos deben estar distribuidos en el siguiente orden.

  • Declaraciones de pragma

  • Importar declaraciones

  • Interfaces

  • Libraries

  • Contracts

Dentro de las interfaces, bibliotecas o contratos, el orden debe ser el siguiente:

  • Declaraciones de tipo

  • Variables de estado

  • Events

  • Functions

Convenciones de nombres

  • El contrato y la biblioteca deben nombrarse usando CapWords Style. Por ejemplo, SmartContract, Owner, etc.

  • El contrato y el nombre de la biblioteca deben coincidir con sus nombres de archivo.

  • En caso de varios contratos / bibliotecas en un archivo, use el nombre del contrato / biblioteca principal.

Own.sol

pragma solidity ^0.5.0;

// Owned.sol
contract Owned {
   address public owner;
   constructor() public {
      owner = msg.sender;
   }
   modifier onlyOwner {
      //....
   }
   function transferOwnership(address newOwner) public onlyOwner {
      //...
   }
}

Congress.sol

pragma solidity ^0.5.0;

// Congress.sol
import "./Owned.sol";

contract Congress is Owned, TokenRecipient {
   //...
}

  • Nombres de estructuras

    - Utilice el estilo CapWords como SmartCoin.

  • Nombres de eventos

    - Utilice el estilo de CapWords como Depósito, AfterTransfer.

  • Nombres de funciones

    - Utilice MixedCase Style como initiateSupply.

  • Variables locales y estatales

    - Utilice MixedCase Style como creatorAddress, suministro.

  • Constantes

    - Utilice todas las letras mayúsculas con subrayado para separar palabras como MAX_BLOCKS.

  • Nombres de modificadores

    - Utilice mixCase Style como onlyAfter.

  • Nombres de enumeración

    - Utilice el estilo de CapWords como TokenGroup.