As a new developer to solidity sometimes it can be confusing looking at the syntax of some codes. Today, we will be handling functions.
I used to wonder, why does the structure of some functions appear to take parameters twice or include parameters in different position. I did a lil digging and here's what I found.
Solidity, the programming language for writing smart contracts on Ethereum and other blockchain platforms, has a unique syntax that can be confusing for beginners. One area is the structure of functions, especially when parameters seem to appear twice or are placed in different positions. This article will break down the structure of Solidity functions and explain why this happens in simple terms.
function functionName(parameterType parameterName) visibility modifier returns (returnType) {
// Function body
}
functionName: The name of the function.
Parameters: Declared in parenthesis (parameterType parameterName) immediately after the function keyword.
Visibility: Defines who can call the function (e.g., public, private, internal, external).
Modifiers: Keywords that alter the behavior of the function (e.g., payable, view, pure, or custom modifiers).
Returns: Specifies the type of value(s) the function will return.
When this happens it's usually due to the following reasons:
Modifiers in Solidity are reusable pieces of code that can add functionality to functions. Modifiers can also take arguments, which are separate from the function’s parameters.
modifier onlyOwner(address _owner) {
require(msg.sender == _owner, "Not the owner");
_;
}
function updateOwner(address _newOwner) public onlyOwner(msg.sender) {
//function body
}
The onlyOwner modifier takes _owner as a parameter.
The updateOwner function has its own _newowner parameter.
The parameters of the modifier and the function are independent but may seem repetitive because they serve different purposes.
When Contracts are inheriting other contracts, they can sometimes override functions from the parent contract. When this happens the overriding function should match the parents functions signature including the parameters.
Example
contract Parent { function something(uint x) public virtual return (uint) return Y +1; } } contract Child is Parent { function something(uint x) public overide returns (uint) { return Y + 2; }
something function in Child matches the parameter (uint x) of the parent function in Parent. this makes sure that the child contract will follow the parent's interface.
In Solidity, the placement of parameters, visibility, and modifiers is part of the language’s syntax. Here’s the order:
Function Parameters: Always declared first, directly after the function keyword.
Visibility and Modifiers: Come after the parameters to define who can call the function and its behavior.
Return Parameters: Declared after the returns keyword, specifying the type of value(s) the function will return
I am yet to fully understand this but this is what I gathered.
Sometimes you will find low-level functions like call or delegate call. They are basically functions that interact with other contracts and they use encoded parameters that will look different from regular parameters.
(bool success, bytes memory data) = address(otherContract).call(
abi.encodeWithSignature("doSomething(uint256)", 123)
);
Parameters for the Something function {i wrote on the previous example} are passed via abi.encodeWithSignature.
The call function itself has its own parameters and return values.
Start Simple: Focus on understanding basic function structures before diving into modifiers and low-level calls.
Read the Documentation: Solidity’s official documentation is a great resource for learning the syntax and features. READ DOCUMENTATION!!
Practice: Build small contracts to experiment with different function structures and see how they behave.
Ask Questions: Don’t hesitate to seek help from the Solidity community or forums when you encounter something confusing.
The structure of Solidity functions is designed to be logical and flexible, even if it seems complex at first. By understanding how parameters, visibility, modifiers, and return types fit together, We can write clear and effective smart contracts. We should keep practicing, and soon this will become second nature!
KEEP BUILDING.
Share Dialog
<100 subscribers
Lady.In.Stem