DEV Community: Perelyn-sama

NatSpec: The Right way to comment Ethereum smart contracts.

Perelyn-sama — Mon, 20 Jun 2022 18:32:26 +0000

Introduction

While writing any sort of program, it is recommended that the code should be kept clean and properly documented as the saying goes “clean code is good code”. Smart contracts are not exempted from this and, they are needed more in smart contracts, this is because of several reasons including the fact that the code of smart contracts are open-sourced making them accessible to everyone who would desire to read them. Since the code of your smart contract is open to the general public, properly commenting on your code is very important because it makes it easier for other developers and curious users to understand your code.

Another more crucial reason for commenting on your smart contracts is to make it easier for auditing companies to audit your smart contract since they are provided with in-depth information about what each contract, library and function is expected to do. With this information, auditors can spend more time trying to spot vulnerabilities in your smart contract rather than trying to figure out the intent behind your code.

By now you should see the importance of documenting your smart contracts and you’re properly wondering how you can get started and what principles you are to follow. Thankfully the solidity team has introduced a format that solidity smart contract developers can follow called the Ethereum Natural Language Specification Format (NatSpec) and for the rest of this article we will be taking a deep dive into what NatSpec is and how we can use it effectively while writing smart contracts.

What is NatSpec?

NatSpec is a documentation format created by the solidity team which was inspired by Doxygen. it helps you describe the intent behind the code of your solidity smart contracts which could be usefully for the author themselves and other people who might be interested in your code like other developers, users and auditors. NatSpec does not only help describe the intent of your code, it also tells the readers how to interact with it too.

If your solidity smart contract is commented with NatSpec you could also use it to automatically generate documentation for your code and some tags like @notice can be displayed in the frontend of your smart contract while users are calling particular functions.

NatSpec Tags

Tags are an essential part of NatSpec, they are used to provide information on particular areas in your smart contract. Tags in NatSpec are as follow:

@title: Should provide information on the title of a contract or interface.
@author: Should provide information about the author of a contract, library or interface.
@notice: Should provide information to the end-user about what a contract, library, interface, function, public state variable or event does.
@dev: Should provide extra information about the contract, library, interface, function, state variable or event to a developer.
@param: Should provide information about the parameters of functions or events followed by the parameter name.
@return: Should provide information about the return variables of a contract’s function.
@inheritdoc: Copies all missing tags from the base function (must be followed by the contract name)
@custom:…: Custom tag, semantics is application-defined

Here’s a cheat sheet of the above tags from the solidity docs:

NatSpec Example

In another one of my articles where I write about Foundry, I employ the use of an ERC20 contract as a test subject to show readers how to use Foundry, admittedly the code for that contract was poorly commented so let’s fix that.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

/// @title An ERC20 contract named MyToken
/// @author Perelyn
/// @notice Serves as a fungible token
/// @dev Inherits the OpenZepplin ERC20 implentation
contract MyToken is ERC20 {

    /// @notice Deployer of the smart contract
    /// @dev Only the owner can call the mint and burn functions
    /// @return owner the address of this smart contract's deployer
    address public owner;

    /// @notice Deploys the smart contract and creates 1000 tokens
    /// @dev Assigns `msg.sender` to the owner state variable
    constructor() ERC20("My Token", "MTKN") {
        owner = msg.sender;
        _mint(msg.sender, 1000 * 10**decimals());
    }

    /// @notice Creates `MyToken` tokens and increases the total supply
    /// @dev Function can only be called by the contract's deployer
    /// @param account The address of the account that will receive the newly created tokens
    /// @param amount The amount of tokens `account` will receive
    function mint(address account, uint256 amount) public {
        require(msg.sender == owner, "Only Owner can mint");
        _mint(account, amount);
    }

    /// @notice Destorys `MyToken` tokens and decreases the total supply
    /// @dev Function can only be called by the contract's deployer
    /// @param account The address of the account that will receive the newly created tokens
    /// @param amount The amount of tokens `account` will receive
    function burn(address account, uint256 amount) public {
        require(msg.sender == owner, "Only Owner can burn");
        _burn(account, amount);
    }
}

Looks good, doesn’t it? For extra context, in a situation when @notice is not available /// could serve as a substitute for it.

Generating Documentation

Remember I said we could generate documentation from NatSpec comments for our smart contracts, It's time we put that to action.

The first thing you need to do to be able to generate documentation is to have the solidity compiler solc on your machine. Follow this link for guides on how you can install solc on your machine.

Run this command to be sure you have solc on your machine:

# on Linux 
solc --version

# on windows 
solcjs -V

Now that you have solc on your machine let’s get started. Remember that @notice is supposed to be shown to users and @dev provides information for other developers, this division gives us the ability to create two types of documentation. We can generate documentation for users which would only include information from the @notice comments and another for developers which would only include information from the @dev comments.

The following command can generate user documentation of a smart contract:

solc --userdoc --pretty-json <contract_file>

The following command can generate developer documentation of a smart contract:

solc --devdoc --pretty-json <contract_file>

Yeah, it's that easy.

💡 Note: The —pretty-json tag is not needed to generate the documentation but to format the output in the terminal.

For a better illustration let’s try testing out these commands. First, you have to create a directory called NatSpec and then create a file inside it called EtherWallet.sol inside this file, paste in the code below:

// SPDX-License-Identifier: MIT
pragma solidity >=0.4.0 <0.9.0;

contract EtherWallet {
    address public owner;

    constructor(){
        owner = msg.sender;
    }

    receive() external payable {}

    function withdraw(uint _amount) external {
        require(msg.sender == owner, "Caller is not owner");
        payable(msg.sender).transfer(_amount);
    }

    function getBalance( ) external view returns (uint) {
        return address(this).balance;
    }
}

Notice that the code does not have comments, I did this on purpose so you can try out commenting it yourself as a way of practising what you have learned so far. All this contract does is try to act like a wallet for storing Ether and also give users the ability to withdraw their Ether and check the balance of the contract. If you do not want to go through this exercise it's okay, the commented version will be at the bottom of the article.

💡 Note: The Author of the above code is Smart contract Programmer and I got the code from his solidity by example.

Once you are done with that, open up your terminal and run the following command:

solc --userdoc --pretty-json EtherWallet.sol

======= EtherWallet.sol:EtherWallet =======
User Documentation
{
  "kind": "user",
  "methods":
  {
    "constructor":
    {
      "notice": "Deploys the contract"
    },
    "getBalance()":
    {
      "notice": "Get the balance of the contract"
    },
    "owner()":
    {
      "notice": "Get the address of owner of the contract"
    },
    "withdraw(uint256)":
    {
      "notice": "Withdraw Ether from the contract"
    }
  },
  "notice": "A Smart contract for storing Ether",
  "version": 1
}

Remember when using the —userdoc command, the documentation provided will only display the @notice comments and ignore the @dev ones.

Now let's try generating the developer documentation.

solc --devdoc --pretty-json EtherWallet.sol

Here’s a clearer version incase the screenshot was not good enough:

======= EtherWallet.sol:EtherWallet =======
Developer Documentation
{
  "author": "smart contract programmer",
  "details": "No deposit function, Ether has to be sent directly",
  "kind": "dev",
  "methods":
  {
    "constructor":
    {
      "details": "sets `msg.sender` as the owner of the contract"
    },
    "getBalance()":
    {
      "details": "Uses address(this) to get the address of the contract and .balance to get the balance of the address",
      "returns":
      {
        "_0": "balance the amount of Ether in the contract"
      }
    },
    "withdraw(uint256)":
    {
      "details": "Function can only be called by the deployer of the contract",
      "params":
      {
        "_amount": "the amount"
      }
    }
  },
  "stateVariables":
  {
    "owner":
    {
      "details": "Owner is set at deployment",
      "return": "owner the deployer of the Ether wallet",
      "returns":
      {
        "_0": "owner the deployer of the Ether wallet"
      }
    }
  },
  "title": "Ether Wallet",
  "version": 1
}

Notice how the developer documentation contains the @dev, @param and @returns but excludes @notice.

Conclusion

Blockchain technology is a very interesting innovation. It has opened ways for humans to interact and work together with each other without worry and fear. You do not have to worry about trusting people because the system itself is trustless. To maintain this amazing feat, we developers have to play our part in contributing to a truly decentralized future and properly documenting the code of our smart contracts for others to quickly understand whether they might be users, developers or auditors. This might seem insignificant but trust me, it goes a long way.

Till next time, Fren^-^.

Here’s the commented version of EtherWallet I promised.

// SPDX-License-Identifier: MIT
pragma solidity >=0.4.0 <0.9.0;

/// @title Ether Wallet
/// @author smart contract programmer
/// @notice A Smart contract for storing Ether
/// @dev No deposit function, Ether has to be sent directly
contract EtherWallet {
    /// @notice Get the address of owner of the contract
    /// @dev Owner is set at deployment
    /// @return owner the deployer of the Ether wallet
    address public owner;

    /// @notice Deploys the contract
    /// @dev sets `msg.sender` as the owner of the contract
    constructor() {
        owner = msg.sender;
    }

    /// @notice Receive Ether
    /// @dev alternative would be a deposit function
    receive() external payable {}

    /// @notice Withdraw Ether from the contract
    /// @dev Function can only be called by the deployer of the contract
    /// @param _amount the amount
    function withdraw(uint256 _amount) external {
        require(msg.sender == owner, "Caller is not owner");
        payable(msg.sender).transfer(_amount);
    }

    /// @notice Get the balance of the contract
    /// @dev Uses address(this) to get the address of the contract and .balance to get the balance of the address
    /// @return balance the amount of Ether in the contract
    function getBalance() external view returns (uint256) {
        return address(this).balance;
    }
}

Demystifying Foundry

Perelyn-sama — Mon, 20 Jun 2022 01:15:07 +0000

Introduction

If you're like me, you probably like trying out different technologies just for the fun of it and maybe you've been hearing everyone talk about Foundry and you don't know what it is or have the time to research about it or even go through the foundry book. Well, if you fit into this category, this article is for you because I'll be talking about what foundry is, why I think you should use it and how you can use it.

What is Foundry?

According to the foundry book:

Foundry is a smart contract development toolchain.
Foundry manages your dependencies, compiles your project, runs tests, deploys, and lets you interact with the chain from the command line.

You might be thinking isn't that what hardhat and truffle already do? Yeah, you're right but Foundry does it faster and personally, I think the best thing about Foundry is the tests. Usually, when working with hardhat or truffle, during smart contracts development you need to write tests for your smart contracts and they're usually in JavaScript. Some may enjoy this but not everyone enjoys switching between languages as they work and let's not forget the fact that not everyone knows JavaScript.

Foundry takes a different approach with writing tests for smart contracts, tests are written in solidity and developers are given the ability to manipulate their test EVM environment to an unbelievable length and are also introduced to various types of tests, not just plain old unit tests. Foundry introduces smart contract developers to other types of testing such as Fuzzing, differential testing and other goodies that the Foundry team are still working on behind the scenes.

At this point, you might be thinking “yeah, it has fancy tests so what?”, whether you thought of that or not I would like to stress the importance of testing smart contracts. At this early stage of blockchain technology in general, we are faced with various issues and one of the most annoying ones is security exploits on smart contracts which leads to the loss of millions of dollars in various protocols. These exploits push the reality of mass adoption of blockchain technologies further and further away and as blockchain developers, we do not want that because definitely when the ecosystem grows, so do we and that's why it is important for you to have a tool like Foundry in your arsenal to help you test your smart contracts beyond what other existing tools provide.

Installation

So now that you understand the usefulness of Foundry, it's time you add it to your development toolkit.

On Linux and macOS

If you use Linux or macOS, you can get Foundry by the following the steps:
Install the latest release by using foundry up

This is the easiest option for Linux and macOS users.
Open your terminal and type in the following command:

curl -L https://foundry.paradigm.xyz | bash

This will download foundryup. Then install Foundry by running:

foundryup

If everything goes well, you will now have three binaries at your disposal: forge, cast and anvil.

On Windows, build from source

If you use Windows, you need to build from source to get Foundry.

Download and run rustup-init from rustup.rs. It will start the installation in a console.

After this, run the following to build Foundry from source:


cargo install --git https://github.com/foundry-rs/foundry foundry-cli anvil --bins --locked

To update from source, run the same command again.

Getting Started

Now that we have Foundry installed on our machine, let’s do something with it and I think building, testing, deploying and verifying an ERC20 contract with Foundry would not hurt.

We will start by creating a Foundry project, first, go into the directory you want to create your project in then run the following commands:

# creates foundry project
forge init hey-foundry

# navigates into the project
cd hey-foundry 

# shows you the content of the project
tree -L 2

These commands should create a new Foundry project called hey-foundry , enter the directory of the project then show you the contents of your project.

In our newly generated Foundry project, we have three directories and one toml file which are:

src
test
script
lib
foundry.toml

Now let’s talk briefly about what each of them is for, the src directory is where our smart contracts are kept, the test directory is where we write our tests, the script directory is where we store how solidity scripts, the lib directory is similar to a node_modules directory and it contains dependencies we install and finally we have the foundry.toml file, which we use to configure the behaviour of our foundry project.

💡 Note: the src, testand script directories both have one file each in them by default called Contract.sol, Contract.t.sol and Contract.s.sol respectively. The lib directory has a folder in it too called forge-std.

Next, you should open the hey-foundry project in your preferred code editor.

Instead of writing our own ERC20 contract from scratch, let’s use the OpenZeppelin implementation and what’s a better way to use their contracts than installing their contracts into our project, so we can import them for our usage. Usually, with other toolchains, we would need to use the Node Package Manager(NPM) to install the OpenZeppelin contracts but with Foundry, we have the privilege to use something that is faster and also has less baggage. To install the OpenZeppelin contracts into our project we would need to run the following command:

forge install OpenZeppelin/openzeppelin-contracts

If you check the lib directory you should you should see the openzeppelin-contracts folder.

Now open the src directory and delete the Contract.sol file and create a new file called MyToken.sol, the contents of this file should look like this:

Now open the src directory and rename the Contract.sol file as MyToken.sol then copy and paste the code below into it.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MyToken is ERC20 {
    address public owner;

    constructor() ERC20("My Token", "MTKN") {
        owner = msg.sender;
        _mint(msg.sender, 1000 * 10**decimals());
    }

    function mint(address account, uint256 amount) public {
        require(msg.sender == owner, "Only Owner can mint");
        _mint(account, amount);
    }

    function burn(address account, uint256 amount) public {
        require(msg.sender == owner, "Only Owner can burn");
        _burn(account, amount);
    }
}

In your code editor you should be getting an error on line 4 import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; , this is because your code editor cannot find the path to the file we want to import. We can fix this by running:

forge remappings > remappings.txt

This should create a remappings.txt file which contains the path to all the dependencies that we have installed in our project and we can use this file to direct other files that want to import our dependencies on where they can get it. The contents of this file should look like this:

openzeppelin-contracts/=lib/openzeppelin-contracts/
forge-std/=lib/forge-std/src/
ds-test/=lib/forge-std/lib/ds-test/src/

And remember our MyToken.sol file is trying to import the OpenZeppelin ERC20 contract from @openzeppelin which would work if we had installed the dependency with NPM but since we installed it with forge we have to do a little tweaking. Don’t worry it’s not that complex all we have to do is change the line that has openzeppelin-contracts/=lib/openzeppelin-contracts/ in the remappings.txt file to this:

@openzeppelin/=lib/openzeppelin-contracts/

If you followed the steps correctly, you should notice that the error has been resolved. This is not the only way to solve this error but for simplicity's sake, we’ll just go with this for now.

Testing our contract

Now that we are done writing our smart contract, it is ideal we test it. So as we did before, rename the Contract.t.sol file as MyToken.t.sol. Once you’re done copy and paste the following code into the file.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import "forge-std/Test.sol";
import "../src/MyToken.sol";

contract MyTokenTest is Test {
    // Target contract
    MyToken myToken;

    // Actors
    address owner;
    address ZERO_ADDRESS = address(0);
    address spender = address(1);
    address user = address(2);

    // Test params
    string public name = "My Token";
    string public symbol = "MTKN";

    uint256 public decimals = 18;
    uint256 amount = 1000 * 1e18;
    uint256 public initialSupply = 1000 * 1e18;

    event Transfer(address indexed from, address indexed to, uint256 value);

    //  =====   Set up  =====

    function setUp() public {
        owner = address(this);
        myToken = new MyToken();
    }

    //  =====   Initial state   =====

    /**
     *  @dev Tests the relevant initial state of the contract.
     *
     *  - Token name is 'My Token'
     *  - Token symbol is 'MTKN'
     *  - Token initail supply is '1000000000000000000000'
     *  - Token decimals is '18'
     */
    function testinitialState() public {
        // assert if the corrent name was used
        assertEq(myToken.name(), name);

        // assert if the correct symbol was used
        assertEq(myToken.symbol(), symbol);

        // assert if the correct initial supply was set
        assertEq(myToken.totalSupply(), initialSupply);

        // assert if the correct decimal was set
        assertEq(myToken.decimals(), decimals);
    }

    //  =====   Functionality tests   =====

    /// @dev Test `mint`

    // Only Owner should be able to mint
    function testFailUnauthorizedMinter() public {
        vm.prank(user);
        myToken.mint(user, amount);
    }

    // Should not be able to mint to the zero address
    function testFailMintToZeroAddress() public {
        vm.prank(owner);
        myToken.mint(ZERO_ADDRESS, amount);
    }

    // Should increase total supply
    function testIncreseTotalSupply() public {
        uint256 expectedSupply = initialSupply + amount;
        vm.prank(owner);
        myToken.mint(owner, amount);
        assertEq(myToken.totalSupply(), expectedSupply);
    }

    // Should increase recipient balance
    function testIncreaseRecipientBalance() public {
        vm.prank(owner);
        myToken.mint(user, amount);
        assertEq(myToken.balanceOf(user), amount);
    }

    // Should emit Transfer event
    function testEmitTransferEventForMint() public {
        vm.expectEmit(true, true, false, true);
        emit Transfer(ZERO_ADDRESS, user, amount);
        vm.prank(owner);
        myToken.mint(user, amount);
    }
}

Don’t worry if some of it seems weird to you now, by the end of the tutorial you should have a good understanding of what is happening in the code above but for now just know we’re writing unit tests for our MyToken.sol contract.

We’ll now go through the code together line by line.

import "forge-std/Test.sol";
import "../src/MyToken.sol";

Over here, we import two files, the contract we want to test - MyToken.sol and a contract containing utilities we’ll need while testing our contract - Test.sol from the forge standard library.

contract MyTokenTest is Test {

We create a contract named MyTokenTest and inherit the Test contract from "forge-std/Test.sol".

  // Target contract
    MyToken myToken;

    // Actors
    address owner;
    address ZERO_ADDRESS = address(0);
    address spender = address(1);
    address user = address(2);

    // Test params
    string public name = "My Token";
    string public symbol = "MTKN";

    uint256 public decimals = 18;
    uint256 amount = 1000 * 1e18;
    uint256 public initialSupply = 1000 * 1e18;

    event Transfer(address indexed from, address indexed to, uint256 value);

Think of these guys as the variables we need to make our tests work.

    //  =====   Set up  =====

    function setUp() public {
        owner = address(this);
        myToken = new MyToken();
    }

This is an important function that is used when writing Foundry tests, as the name implies we are setting up our test. We usually do things like deploying our contracts in it and that’s what we’re doing here, we’re also assigning an address to the owner state variable. The address of the MyTokenTest is set as the owner because it is the address that deploys it.

    //  =====   Initial state   =====

    /**
     *  @dev Tests the relevant initial state of the contract.
     *
     *  - Token name is 'My Token'
     *  - Token symbol is 'MTKN'
     *  - Token initail supply is '1000000000000000000000'
     *  - Token decimals is '18'
     */
    function testinitialState() public {
        // assert if the corrent name was used
        assertEq(myToken.name(), name);

        // assert if the correct symbol was used
        assertEq(myToken.symbol(), symbol);

        // assert if the correct initial supply was set
        assertEq(myToken.totalSupply(), initialSupply);

        // assert if the correct decimal was set
        assertEq(myToken.decimals(), decimals);
    }

Over here we are testing for the initial state of the MyToken contract we just deployed in the setUp function. Since we assigned the deployed contract to the identifier myToken, we can invoke functions in it by writing myToken.<function_name>().

ERC20 tokens usually have a name, symbol, initial supply and decimals, so here we’re trying to check if the correct ones were set. We do this by using the assertEq function, which checks if the two parameters passed into it are equal.

💡 Note: We get the assertEq function from the Test.sol file we imported earlier.

  //  =====   Functionality tests   =====

    /// @dev Test `mint`

    // Only Owner should be able to mint
    function testFailUnauthorizedMinter() public {
        vm.prank(user);
        myToken.mint(user, amount);
    }

    // Should not be able to mint to the zero address
    function testFailMintToZeroAddress() public {
        vm.prank(owner);
        myToken.mint(ZERO_ADDRESS, amount);
    }

    // Should increase total supply
    function testIncreseTotalSupply() public {
        uint256 expectedSupply = initialSupply + amount;
        vm.prank(owner);
        myToken.mint(owner, amount);
        assertEq(myToken.totalSupply(), expectedSupply);
    }

    // Should increase recipient balance
    function testIncreaseRecipientBalance() public {
        vm.prank(owner);
        myToken.mint(user, amount);
        assertEq(myToken.balanceOf(user), amount);
    }

    // Should emit Transfer event
    function testEmitTransferEventForMint() public {
        vm.expectEmit(true, true, false, true);
        emit Transfer(ZERO_ADDRESS, user, amount);
        vm.prank(owner);
        myToken.mint(user, amount);
    }

In this part of the code, we test the mint function for different cases in a series of functions. The comments I added at the top of each function should provide enough information about what they do, although the lines where I used vm.prank() and vm.expectEmit() may seem alien to you.

These two functions are examples of what are known as cheat codes in Foundry, we use them to manipulate the test EVM environment to procure real-life situations, and there are cheat codes to manipulate block.timestamp , block.number, the nonce and so much more.

So what are vm.prank() and vm.expectEmit() used for? vm.prank() is used to change the msg.sender of the next call and you pass the address you want the next call to use as msg.sender into vm.prank as a parameter while vm.expectEmit on the other hand, helps us check if the next event emitted in a function is what we expect.

💡 For more information on Foundry cheat codes, check out this link. For more information on vm.prank() and vm.expectEmit() check out the following links respectively, vm.prank() and vm.expectEmit().

Now that you understand the code, let’s run it. We run tests in Foundry with the following command:

forge test

After running forge test , you should see this in your terminal:

And with that, we’re done testing our contract. Congrats for making it this far, here have some coffee ☕.

Deploying and Verifying

Prior to now, we would run extensive commands in our terminal to deploy our contracts but recently the Foundry team introduced something phenomenal and that’s solidity scripting. If you have experience using hardhat you should be familiar with using scripts to deploy smart contracts, that’s practically the same thing we’re doing here but instead of writing our scripts in JavaScript, we write them in solidity instead.

Now, that we have the theoretical part out of the way let’s get coding. First of all, we would need to rename the Contract.s.sol file that’s in the script directory to MyToken.s.sol.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import "forge-std/Script.sol";
import "../src/MyToken.sol";

contract MyTokenScript is Script {
    function run() external {
        vm.startBroadcast();
        MyToken myToken = new MyToken();
    }
}

Our script is pretty similar to a normal solidity smart contract so it easy to understand. Basically, it is a contract that has one function called run and that’s where we deploy our contract, the only thing that is alien here is vm.startBroadcast. All vm.startBroadcast does is create transactions that can later be signed and sent onchain.

Now that we have written our script, it is time we run this code so we can deploy our contract to the Rinkeby testnet but before we do that we have to create a .env file storing our Rinkeby RPC URL, private key and Etherscan key . The .env file should have the following variables provided:

RINKEBY_RPC_URL=
PRIVATE_KEY=
ETHERSCAN_KEY=

Next, we run the following commands :

# To give our shell access to our environment variables
source .env

# To deploy and verify our contract
forge script script/MyToken.s.sol:MyScript --rpc-url $RINKEBY_RPC_URL  --private-key $PRIVATE_KEY --broadcast --verify --etherscan-api-key $ETHERSCAN_KEY -vvvv

Well done! You’ve just deployed the MyToken contract to the Rinkeby network and that’s not all you did, you also verified the contract on Etherscan all with one command.

Conclusion

Although Foundry is a new tool and some developers might be sceptical to use it because of how comfortable they have become with previously existing tools if you’re one of them I would ask you to give Foundry a shot because Foundry is a tool that is beyond its time and is essential to the general advancement of the Smart contract development community.

In this tutorial, we only covered the surface of Foundry. To learn more about Foundry you could try going through the Foundry book and use Foundry more. Thanks for reading till next time Fren^-^.

Getting the frequency of an element in an array in JavaScript

Perelyn-sama — Sun, 06 Dec 2020 12:22:34 +0000

First of all, what is frequency?
According to Wikipedia, it's" the rate at which something occurs over a particular period of time or in a given sample."
There are multiple ways to get the frequency of an element in an array. In this article, we'll focus on one of those ways by using some of the higher-order functions in Javascript.

Let's begin

For instance, if we have an array of letters:

const letters = ["a", "b", "c", "a", "b", "c", "a", "b"];

To get the frequency of each element, we will first need to create an empty object named count:

const count = {};

Next, we'll utilize one those higher order functions we were talking about:

letters.forEach(e => count[e] ? count[e]++ : count[e] = 1 );

What the above code does is simply check, if each element of letters is present in count. Initially count is empty and does not contain any of letters elements, so when the ternary operator runs on an element of letters to check if its present in count for the first time, it's going to work with the falsy condition which is to assign letters elements to 1 in the count object.
So the count object will then become:

console.log(count) // {"a" : 1, "b" : 1, "c" : 1};

Afterward, when the ternary operator checks if count has an element of letters that has already been checked, the ternary operator will then run the truthy condition which is to increment the value of the elements in letters if they are already present in count, so count will now become:

console.log(count) // {"a" : 3, "b" : , "c" : 2};

And just like that ladies and gentlemen, we've been able to get the frequency of each element of letters.

Conclusion

Here's the complete code:

const letters = ["a", "b", "c", "a", "b", "c", "a", "b"];
const count = {};
letters.forEach(e => count[e] ? count[e]++ : count[e] = 1 );

console.log(count) // {"a" : 1, "b" : 1, "c" : 1}

P.S: This code can be used for both strings and numbers.

The Programmer's path

Perelyn-sama — Wed, 25 Nov 2020 18:46:14 +0000

The path of becoming a programmer is easier than most newbies would think, Yes the road is long, tedious, and too often tests our patience and confidence, it still is a profession that anyone with enough zeal and passion can overcome. Most times all we need to do is just start the race than thinking about all the wrong things that could go wrong. I'm not a stranger to anxiety, I know how it feels to not know what to do in the right situation that's why I've come up with these tips to help you on your journey.

Join Freecodecamp

A lot of the experienced developers, we know today started with FCC(Freecodecamp) because of its rich content and a magical way of presenting its content to users. Its beginner-friendly, free, and has a large community that is tolerant towards newbies and their questions. I would advise every beginner to start at FCC because its curriculum really simplifies coding concepts and it also provides a wide range of topics like HTML, CSS, JavaScript, Frameworks and so much more. Here's their website Freecodecamp check it out, I'm sure you will love it.

Get a code editor

The most essential magic sauce to every programmer's growth is practice! And you can't practice coding without a code editor. So now what code editor should you use? I would suggest Visual Studio Code, it's a code editor that was made by Mircosoft and in my opinion, it provides the most beginner-friendly environment any code newbie could ask for. Here's the link to download their software Vs Code.

Join a dev community!

Being around people who are interested in the same thing you are is a blessing that everyone should enjoy. When you are in a community you learn things that will help boost your programming skills and even when you become a pro, your community can help you get job offers! One of my favorite dev communities is the twitter community, there you can get expos from senior developers and a limitless supply of resources that will surely help your growth. Now you would think how do I join the Twitter community well that's very easy all you need to do is follow senior developers' accounts, along with tech topics, and most importantly interact and ask questions. A common practice in the twitter developers community is the 100 days of code challenge, in this challenge you have to code at least an hour every day and post what you learned each day along with the tag #100DaysOfCode. Here's a link to expand your knowledge on the challenge link.

Conclusion

Many times on this path, you'll want to quit and just give up but just keep on and don't feel that you're weak, everyone gets this feeling and has to learn to move past it individually. Another thing to remember is to always be consistent, try to learn something new every single day and you'll find your skill improving rapidly! Good luck.