Now let's go ahead and learn to make our first function. Basic Solidity functions, section functions or methods. Functions or methods are a subsection of code that when called will execute a very specific, small piece of our entire code base. If you're familiar with JavaScript or Python or any other programming language,

functions in Solidity are exactly the same. Functions are identified by the keyword `function`. Let's create a function and name it `store`, and we're going to have this function be responsible for actually updating our favorite number. We're going to store a new favorite number. So you first write the `function` keyword, the name of the function, and then you add these two parentheses. Whatever is in between these two parentheses represents what we're going to pass or send to our function, or the parameters that we're going to send to our function. For example, we need to tell

our `store` function what value it should use to update `favoriteNumber`. So we're going to tell our `store` function it should take a `uint256`, and this variable that we're going to pass to it, we're going to call `_favoriteNumber`. It's important that we give it a

different name than `favoriteNumber` up here, and we'll talk about that in a little bit. Then we're going to say this is going to be a `public` function, and we'll explain that soon too. We want to put these little curly brackets in here as well, and we're just going to say

`favoriteNumber` equals `_favoriteNumber`. And without going too deep into what this is doing, we're saying… I'm not going to explain `public` yet, but we will in a minute. But what we're saying is whenever you call this `store` function, you're going to set our

favorite number equals underscore favorite number. And without going too deep into what this is doing, we're saying… I'm not going to explain public yet, but we will in a minute. But what we're saying is whenever you call this store function, you're going to set our

favorite number variable to whatever variable that we passed. I'll explain why we do this underscore here as well in a little bit. And with just this, we can actually start to simulate what this smart contract will do and if our store function will actually work correctly so

what we can do with just this code right here is come over back to the compile tab and hit compile, make sure that we get this green check mark and that everything looks good. And then we can go down to this deploy and run transactions tab, our deploy and run transactions tab

has a ton of different parameters in here on how to actually deploy and run with our transactions. We're going to deploy this contract to a simulated virtual environment so we're going to deploy it basically to a fake environment. We're not going to be deploying it to a test net that we're going

to deploy it basically in kind of an imaginary world in order for us to do this first. Make sure we're on this remix VM and for us we're going to just use the default, which is the merge. It doesn't really matter which one you're on, just

so long as it's the remix VM. This remix VM is a fake local blockchain where we don't have to wait for transactions to complete and we don't have to deal with any of the oddities on deploying our code to a real test net or

a real mainnet and to worry about the rest of these for now. We also get an account here when we run on our fake remix VM. We get automatically given an account with a different amount of ethereum for each account. You can think of each one of these

accounts similar to our Metamask accounts in Metamask, except these are fake, imaginary accounts that Remix just gives to us for our transactions, including deploying contracts. We're given a gas limit value that we can send, and we'd also choose our contract depending on which one we've compiled.

Since we only have one contract in here, we only have one to choose from. So, on the left-hand side to deploy our contract to this fake Remix VM environment, we're going to go ahead and click the deploy button. If we scroll all the way down to the bottom now, under

this 'Deployed Contracts,' we can see we actually deployed a contract here: SimpleStorage. We can see the balance at zero, and we see this big orange button that says 'Store,' and then you went to '6_favoriteNumber' on our local blockchain. This at blah blah here, this

is going to be the address of our contract, similar to our wallets, how they have different addresses. Every single contract has a unique address as well. And if we hit this little copy button and we close this and we put it as a comment here and we paste it, we can see

this looks exactly similar to an address such as what's in our Metamask. And then let's go ahead and open the deploy back up, and we see that deployed contract is still there. Additionally, if you hit this little 'Show Terminal' button and you pull this up, we can actually see we have this

little comment here: 'Creation of SimpleStorage pending,' and we have this green checkmark here. This is notating that we actually sent a transaction to deploy this contract, similar to sending ETH back and forth. In order for us to deploy a contract, we actually have to send a

transaction since we're doing this on the Remix IDE, this is a simulated transaction, a pretend transaction inside of our Remix environment. You can even hit the little drop down and see even more information about this transaction. You'll see a lot of familiar keywords like status, transaction hash, from, to, gas

etc. Deploying a contract uses the exact same process as sending a transaction for just ETH. The main difference is we populate this data or input field with a ton of that bytecode and if you copy this input field or this data field and go ahead and make a comment in here

you'll see it's a massive line and this massive line notates all the data associated with this smart contract, all the machine-readable code. Remember, anytime we do anything that modifies any value on the blockchain, we actually do that by sending a transaction. Deploying

a contract is modifying the blockchain so we do it in a transaction which means yes, we spend gas. Now this big orange button over here actually resembles our function store in our smart contract and if we add some numbers in here and we call it again, if we pull the terminal up we can see

transact to SimpleStorage, pending and we see we sent a transaction which called this store. If we do this again with a different number, we call it, we can see our terminal says, you sent another transaction to update the state of the blockchain and if we scroll all

the way up to our account you'll see that we have a little less ether in our account because we had to spend the gas associated with, well, A, deploying this contract and then B, calling these functions and then for example, if I add this, if I add 5 in here and hit store

we'll send a transaction to store 5 on the blockchain now you might be thinking okay Patrick that's pretty cool but what is the value of favorite number you're telling me that this function store is updating favorite number but I can't really see it how do I know that favorite

number has actually been updated to five well the reason we can't see it is that the visibility of our favorite number is actually defaulted to internal so us not having anything here or writing internal or actually meaning the same thing and we'll talk about visibility and default

visibilities in a minute but in order for us to actually see the value of our favorite number we'll go ahead and add the public keyword to this this changes the visibility of a favorite number to public and like I said we'll talk about visibility in a minute but let's go

ahead and compile this let's go ahead and delete this contract by hitting this x here and let's redeploy this contract with this new public keyword so let's go ahead and hit deploy and now if we scroll down and we open up our simple storage we actually now see a blue

button labeled favorite number and if we click it now we can see it returns zero which makes sense because we know that uint 256 is defaulted to zero now if I go ahead and add 5 into here and hit the store button if I pull up the terminal

we'll see that we went ahead and executed that store function call that transaction that's going to take input this 5 as favorite number and set it to our favorite number now if I hit favorite number you can see it does indeed return 5 showing that we actually

updated our favorite number with this function call and remember though I'm going to go ahead and do this again and remember when I hit X here this is just removing it from this window here if you actually deploy a smart contract to the blockchain hitting X from this window

doesn't do anything because once you deploy your contract it's immutable it's out there and you can't just delete it by clicking X and remix functions and variables can have one of four different visibility specifiers in Solidity: public, private, external, and internal. If you

don't give one of these keywords to your variables, it'll get defaulted to internal. Public functions mean that they're visible externally and internally, and you'll see here it says it creates a getter function for storage/state variables. This means that other people can call this function or

call this variable. When we didn't have a visibility for favorite number, it defaulted to internal, which is why we didn't see this blue number pop up because internal means that other contracts and people aren't allowed to call on this favorite number. We have a

little bit more here it says it actually creates a getter function for storage state variables when we add this public keyword here it's actually equivalent to us making a getter for this favorite number variable, a getter function, and I'll show you exactly what the function will look like in a little bit. Now keep

in mind though everything on chain is technically public so setting a function or variable to private isn't a good way to hide what the value actually is there, and we'll talk a little bit more about storage and visibility and that much later. Just remember everything on these

EVM chains is actually public data. This public variable just means any other contract can call this `favoriteNumber` and see the value what's in `favoriteNumber`. And private means only the current contract can. External functions mean they're only visible externally, and this is only for functions, not for variables.

And it means another function inside this contract couldn't call an external function. And internal means only the current contract and its child contracts can call the function. We'll talk about child contracts and inheritance in a later section, so let's just keep it public for now. The reason that we have

this underscore here in this parameter is because we need to tell users that this variable in here is different than `favoriteNumber`. And there's a couple different conventions on naming local variables versus these what's known as state variables or variables outside of functions. And we'll go over those later

in the course. Now here's something that's really interesting as well. Remember how I told you earlier that sending ether is a relatively simple transaction, right? Well, let's see what happens when we call this `store` function and we update `favoriteNumber` to five. Let's actually call it

one more time, and we hit the little drop-down here. Let's go to gas, and we'll see gas actually cost 27,000 gas, which is a lot more than the 21,000 gas it costs to just send ether between accounts. Remember every time you

update the state of the blockchain, it's going to cost gas. Now what do you think will happen if we do more inside of this `store` function? For example, we say `favoriteNumber` equals itself plus one. Let's go ahead and compile this. Let's delete our old `SimpleStorage`. Let's

deploy this new one remember the last one cost 27 gas let's pull up the terminal and remix actually gives us a little tooltip saying an infinite gas which we know is actually wrong but let's go ahead and add 1 to 3 in here

and we'll hit store we'll see this transaction we'll scroll down we'll see gas is actually a lot more it's way more gas it's 50 000 gas with just adding this line here now technically I'm not telling the full story here because

there are some other gas costs associated with the first time you run a function but it's still more right and that's what's important here so so let's go ahead and delete that line and go back to our old function here now let's talk about something called scope for a

second so if I create a variable in here called uint256 testVAR equals five and I create a new function called something we'll make it public could I access the testVAR and then maybe change it to six or seven what about the favorite number or what about the favorite number

variable could I access that to seven well let's go ahead and see what happens if we try to compile this we try to compile we actually go ahead and get an error in our compilation Undeclared identifier whenever you create a variable it can only be viewed in the

scope of where it is if that's confusing just look for the curly brackets the reason that are something function can read the testVAR is because this testVAR isn't inside of the curly brackets of something the reason it can't read the testVAR is

because testvar was created way up here inside of these curly brackets outside of something, but favorite number wasn't created inside of these curly brackets. So how come it knows what favorite number is? Well, something is inside of these curly brackets, and favorite number was created inside of all of these curly

brackets. Favorite number was created inside of here. It wouldn't be able to access favorite number because again, favorite number is inside of this scope and not this scope. If you create a variable like testvar inside of store, you can only access this testvar inside

of this store function and not anywhere else. The easy way to know what the scope of a variable is is just look for the curly brackets. So let's go ahead and delete this something variable and let's delete this test file and let's recompile now. Like we were saying

earlier, when we add this public keyword to favorite number, it's the exact same as if we created a getter function to return this favorite number. So let's actually write a function similar to what this public keyword is creating. So we're going to say function retrieve

we'll make this a public view function, and we'll talk about that in just a second. And we'll say it returns a uint256, and we'll add the curly braces here, and we'll say return favorite number. And oftentimes on these auto suggestions

come up like this, you can just hit enter and they will automatically do it. So if we do favorite and then I just hit enter, boom, automatically like that. Now I'm going to hit command s, which is equivalent to me going to the compile tab and hitting compile. Now if I go to

the deploy tab and let's deploy this contract now and we scroll down we now see we still have that store function we have our favorite number function and we have a new blue button called retrieve right now they both start off at zero and then obviously if we update this to

five by calling store yep I called store these are now both return five since favorite number is the actual variable and retrieve is just returning whatever favorite number is now as you can see here these two functions are blue but this one is orange what's the difference

why are the colors different well the key is actually with this view keyword here solidity has a special keyword which notates functions that don't actually have to run or you don't actually have to send a transaction for you to call them and those two keywords

are going to be view and pure a function marked view means we're just going to read state from the blockchain for example in our retrieve function we're just going to read what the favorite number variable is our store function isn't reading it's updating something so

and it's changing the state of the blockchain so we have to send a transaction since our retrieve function doesn't have anything inside here that updates anything it just returns a favorite number we don't need to send a transaction so if you add this view

function in here it disallows any modification of state for example I couldn't add favorite number equals favorite number plus one if we go ahead and try to compile this we'll get an error function cannot be declared as view because this expression potentially modifies state so we'd have to remove this

line, or we'd have to remove the `view` keyword. So view functions disallow updating state. Your functions disallow updating state and they disallow even reading from state or storage. This `favoriteNumber` here is what's known as a storage variable because it's stored in a place called storage.

We'll talk about that in a later section, but if this was labeled `pure`, we'd see we get a little red underscore here because `favoriteNumber` is reading from state instead of returning `favoriteNumber`. We would return something like seven, so this would be an example of a pure

function. This would be an example of a view function because we're reading from state again. We'll explain the difference a little bit later and like I was saying before, if we call a view or a pure function, we actually don't need to spend gas since we're not modifying the state.

That's why these buttons over here are blue; they're representing view or pure functions, functions that we can call without having to send a transaction. For example, if I pull up the terminal here and I pull this up and I call `retrieve`, we do get another function, but it's just

a call, and it looks different than if I hit the `store`, which has this little checkmark. The difference because the `store` is obviously sending a transaction and the `retrieve` is actually just making a call and not sending a transaction. However, something weird is going on here. If I hit `retrieve` and I go into the

details of this call, I can see, oh, what's what's this? Why is there an execution cost? It says `cost only applies when called by a contract`. What's going on there? The reason for that is because if another function that does update state, that does require a transaction, calls

retrieve that transaction does need to pay the gas of reading and calling this retrieve function. So calling a view or pure function actually does cost gas only when a gas cost transaction is calling it. So we can go ahead and call these as much as we want, it costs nothing, but if

another function that does cost gas calls it, it's going to cost something. For example, if our function store here then went ahead and called retrieve like this, since store costs gas, you're telling this function, hey, also call this retrieve function, which is more work for

it to do, and since it's more work, it's going to cost more gas. So for example, if we delete this contract over here, let's go ahead and compile this, let's go ahead and deploy this with this retrieve in here. So let's go ahead and look at these. These are now

zero. We'll store five in here. We'll select the drop down. We can see how much gas we actually sent: 50 000 gas. Let's go ahead and drop this now. Close this out. Let's remove the retrieve line, compile, we'll hit deploy simple storage.

These are both zero. We'll add five, hit store, pull up the terminal, hit the drop down, look at gas, it's still 50 000, but it's actually a little bit less than before, although I'm pointing at gas, we really should be looking at transaction

cost because gas is really just actually how much we're sending whereas transaction cost is how much gas the transaction actually cost. But in any case, it's a little bit less without the retrieve function. Now I've kind of been glossing over this a little bit, but this returns keyword

specifies what this function is going to give us when we call it. So when we have this `return` keyword in our `retrieve` function here, we're saying whenever we call this `retrieve` function, we want to get returned or we want to be given this favorite number of type `U` and 256. We

want to return a `U` and 256 from this function

Lesson 2 Part 4 | Solidity Functions - Solidity & Foundry Full Course

Book a smart contract audit here 👇
https://www.cyfrin.io/


Cyfrin Audits

Functions are subsections of code executing specific tasks when called.

Functions are defined using the `function` keyword, followed by the function name and parentheses for parameters.

Parameters are defined with their type and name (different from state variables).

Example: `store` function updates `favoriteNumber` with a passed `uint256` value.

Deploying and Running Smart Contracts in Remix

Compilation and deployment to a simulated Remix VM environment.

Deployment to a fake environment avoids complexities of testnets/mainnets.

Remix VM provides fake accounts and gas for transactions.

Deployed contract's address is displayed, similar to wallet addresses.

Terminal shows transaction details (status, hash, etc.).

Default visibility is `internal`; `public` makes variables/functions externally accessible.

Visibility specifiers: `public`, `private`, `external`, `internal`.

`public` creates getter functions for state variables.

`internal` restricts access to the current contract.

`external` is for functions only, accessible externally but not internally.

Updating state (e.g., calling `store`) costs more gas than simple ETH transfers.

Adding operations within a function increases gas costs.

Variables are accessible only within their defined scope (curly brackets).

Compilation errors occur when accessing variables outside their scope.

`view` functions read state without modifying it, and don't require transactions.

`view` and `pure` keywords prevent state modification.

`pure` functions neither read nor write from state.

View/pure functions are blue buttons; calls don't send transactions.

Gas cost applies to view/pure functions only when called by a transaction-requiring function.