What Are Enumeration And Functions in Solidity?


Solidity may be a programing language that’s very on the brink of JavaScript. Similarities between JavaScript and C are often found within Solidity. Solidity may be a statically-typed, case-sensitive, and object-oriented programming (OOP) language. Although it’s object-oriented, it supports limited objected orientation features. What this suggests is that variable data types should be defined and known at compile time. Functions and variables should be written in OOP the same way as they’re defined. Cat is different from CAT in Solidity, cat, or the other variation of cat. The statement terminator in Solidity is that the semicolon:;. Solidity code is written in Solidity files that have the extension .sol, they’re human-readable text files that will be opened as text files in any editor including Notepad.

A Solidity file consists of the subsequent four high-level constructs:

  • Pragma
  • Comments
  • Import
  • Contracts/library/interface


The enum keyword is employed to declare enumerations. Enumerations help in declaring a custom user-defined data type in Solidity. enum consists of an enumeration list, a predetermined set of named constants. Constant values within an enum are often explicitly converted into integers in Solidity. Each constant value gets an integer value, with the primary one having a worth of 0 and therefore the value of each successive item is increased by 1. An enum declaration uses the enum keyword followed by an enumeration identifier and an inventory of enumeration values within the {} brackets. it’s to be noted that an enum declaration does not have a semicolon as its terminator which there should be a minimum of one member declared within the list.
An example of enum is as follows:
enum gender {male, female} A variable of enumeration are often declared and assigned a worth as shown within the following
gender _gender = gender.male ;
It is not mandatory to define enum during a Solidity contract. enum should be defined if there’s a constant list of things that don’t change just like the example shown previously. These become
good examples for an enum declaration. they assist to make your code more readable and maintainable.


Functions are the guts of Ethereum and Solidity. Ethereum maintains the present state of state variables and executes transactions to vary values in state variables. When a function in a contract is named or invoked, it leads to the creation of a transaction. Functions are the mechanism to read and write values from and to state variables. Functions are a unit of code that can be executed on-demand by calling it. Functions can accept parameters, execute their logic, and optionally return values to the caller. they will be named also anonymous.

Solidity provides named functions with the likelihood of just one unnamed function during a contract called the fallback function. A function is said using the function keyword followed by its identifier— get, in this case. It can accept multiple comma-separated parameters. The parameter identifiers are optional, but data types should be provided within the parameter list. Functions can have modifiers attached, like onlyBy() during this case. There are a few additional qualifiers that affect the behavior and execution of a function. Functions have visibility qualifiers and qualifiers, associated with what actions are often executed within the function. Functions also can return data and this information is said using the return keyword, followed by an inventory of return parameters. Solidity can return multiple parameters.

Functions have visibility qualifiers related to them almost like state variables. The visibility of a function is often anybody of the following:

  • public: This visibility makes function access directly from outside. They become part of the contracts interface and may be called both internally and externally.
  • internal: By default, the state variable has an indoor qualifier if nothing is specified. It means this function can only be used within the present contract and any contract that inherits from it. These functions can’t be accessed from outside. They’re not a part of the contract interface.
  • private: Private functions can only be utilized in contracts declaring them. They cannot be used even within derived contracts. They’re not a part of the contract interface. external: This visibility makes function access directly from externally but not internally. These functions become a part of the contracts interface.

Functions also can have the subsequent additional qualifiers that change their behavior in terms of getting the power to vary contract state variables:

  • constant: These functions don’t have the power to switch the state of the blockchain. They will read the state variables and return them back to the caller, but they cannot modify any variable, invoke an occasion, create another contract, call other functions which will turn, and so on. consider constant functions as functions that will read and return current state variable values.
  • view: These functions are aliases of constant functions.
  • pure: Pure functions further constraint the power of functions. Pure functions can neither read and write—in short, they can’t access state variables. Functions that are declared with this qualifier should make sure that they’re going to not access the current state and transaction variables.
  • payable: Functions declared with the payable keyword have the power to simply accept Ether from the caller. the decision will fail just in case Ether isn’t provided by the sender. A function may only accept Ether if it’s marked as payable. Functions are often invoked by their names.

Mansoor Ahmed

Mansoor Ahmed is Chemical Engineer, web developer, a Tech writer currently living in Pakistan. My interests range from technology to web development. I am also interested in programming, writing, and reading.