Solidity - lesson 1 | HackIndia Skills

Key point

One clean idea

A smart contract is code plus data at an Ethereum address. Your first goal is not to add many features. Your goal is to make the state and the allowed changes obvious.

A recruiter or hackathon judge should understand your contract in one minute, before reading your tests.

What to include

A Solidity contract can contain state variables, functions, modifiers, events, errors, structs, enums, and inheritance. In this first lesson, keep it smaller: state, constructor, function, event, and custom error.

Use Solidity 0.8.x. Do not add pragma experimental ABIEncoderV2. It is an old pattern because ABI coder v2 is already the default in Solidity 0.8.x.

Example

First contract

This example stores one project profile. It is like a mini on-chain record for a HackIndia submission. It has one owner, one public title, and a way to update the title.

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

contract ProjectProfile {
    address public immutable owner;
    string public title;

    error NotOwner(address caller);
    error EmptyTitle();

    event TitleUpdated(string oldTitle, string newTitle);

    constructor(string memory initialTitle) {
        if (bytes(initialTitle).length == 0) {
            revert EmptyTitle();
        }

        owner = msg.sender;
        title = initialTitle;
    }

    function updateTitle(string calldata newTitle) external {
        if (msg.sender != owner) {
            revert NotOwner(msg.sender);
        }

        if (bytes(newTitle).length == 0) {
            revert EmptyTitle();
        }

        string memory oldTitle = title;
        title = newTitle;

        emit TitleUpdated(oldTitle, newTitle);
    }
}

Your to-do

Read the structure

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Start with the SPDX license and pragma so tools know the license and compiler range.
Store only the state you need: owner and title.
Set the owner once in the constructor using msg.sender.
Reject bad input with custom errors instead of silent failure.
Emit an event when important state changes.

0 of 5 done

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to review the contract for readability. Use a narrow prompt: “Check this Solidity 0.8.x contract for old patterns, unclear names, and missing events. Do not rewrite the whole design.”

Check the answer yourself. AI may suggest old habits like SafeMath for normal arithmetic, tx.origin, or send. For Solidity 0.8.x beginner code, those are warning signs.

Common mistake

Avoid tutorial leftovers

Do not use tx.origin for access control. Use msg.sender-style checks like this contract does.

Do not ignore compiler warnings. Modern Solidity warnings often point to real safety or compatibility problems. A clean repo should compile without warnings.

Why this looks credible

The contract is small and easy to review. The owner is immutable, so it cannot be changed after deployment. The update function checks permission, checks input, updates state, and emits an event.

It also avoids Ether handling. That is intentional. Stored Ether, external calls, and withdrawal logic add risk. You will handle safer patterns later in the track.