logoAcademy

Contracts

Learn about Solidity

As the halfway mark between knowing absolutely nothing about programming smart contracts and being able to deploy smart contracts, we arrive at the concept of defining contracts themselves. Recall that smart contracts consist of the following:

  • A state
  • A set of behaviors

We will first start by defining the general structure of a smart contract, before diving into defining each individual component that makes a smart contract what it is.

General Contract Structure

Below is the general syntax for a smart contract in Solidity:

contract <ContractName> {
 
  // State Variables go here
  
  // Contract functions go here
  
}

We declare a contract with the contract keyword, followed by the name of the smart contract (which usually follows CamelCase notation). Afterwards, we use curly brackets to encapsulate the body of the smart contract.

State Variables

The same workflow and rules regarding the declaration and definition of variables apply to variables associated with the state of a smart contract. State variables, as they're called, are persistent between transactions and can only be modified in the following two scenarios:

  • During the initialization of the smart contract itself
  • By a function of the smart contract itself

No other account can modify the variables of a smart contract directly; only the contract itself can. An example of state variables with a smart contract is as follows:

contract A {
 
    uint256 num = 5;
  
}

State Variable Visibility

  • Solidity is an object-oriented programming language (where contracts act as classes) and so as we will see soon, contracts are able to inherit other contracts. However, we still want to define the inheritance properties of the state variables of a contract. Therefore, we introduce state variable visibility. The following are the three possible type of state variable visibilities:
  • Public: the state variable is found in the parent contract and all children contract. Furthermore, any state variable defined as public will contain a getter function of the same name
  • Internal: this is the same as public, except a getter function is not created. Any state variable not annotated with a visibility is, by default, set as internal
  • Private: the state variable is found only in the parent contract - children contract do not inherit the state variable

In this context, the private visibility does not mean that the value of the associated variable is accessible only to the contract. Anyone with access to the blockchain can find the value of a private variable.

Below are examples of explicitly declaring the visibility of state variable:

contract A {

    address private addr;
    uint internal num;
    int public numTwo;
  
}

Contract Functions

Having gone over the state of a contract, we now discuss about contract functions, the second property of smart contracts and the logic that allows us to modify state variables. The same manner in which we declared and defined functions earlier also apply here. The only new thing here, however, is that our contract functions can modify the state variables of the associated contract. As an example, below is a contract with a state variable, and associated functions to get/set the values of the variable:

contract A {
 
    uint num;
  
    function setNum(uint _num) public {
        num = _num; 
    }
  
    function getNum() public view returns(uint) {
        return num; 
    }
 
}

On this page