Exploring solidity - Ethereum Tutorial

- So you've heard a little bit about Solidity. Let's talk about what Solidity actually is. Solidity is a programming language for writing Ethereum smart contracts. There are other languages, Solidity is not the only language you can use, but that's the one we're going to focus on in this course. Solidity is the most popular language in use today for writing Ethereum smart contracts. It looks a lot like JavaScript. In fact, it's somewhat based on JavaScript, so if you already know JavaScript, you're going to really like Solidity. If you don't, though, it's okay. It's pretty easy to learn. There's just a few rules we'll go over, and then you'll pick up the rest as you move along. In this course, we're going to just do a basic introduction to Solidity. We don't have the time to cover everything, so I do encourage you to look up more resources about Solidity and keep learning, 'cause it's a great language. Smart contracts that we write in Solidity are going to run on all EVMs, all nodes. That means that we have to ensure that what we write, or we can assume that what we write is deterministic. In other words, it runs the same way everywhere, every time. Now we do have to be a little concerned about the way we write our code, we don't want to depend on external data that may actually be different on different nodes. We want to make sure that our input data is always the same so we're not depending on anything that changes, so that that output is deterministic. Smart contracts govern how you access the blockchain because you can't access the blockchain without going through a smart contract, so it is kind of like the gatekeeper for the blockchain. Remember, too, that smart contract code, the actual code you write is stored on the blockchain, just like data. So once you deploy code out to the blockchain, it's always going to be there, but you want to make sure it's fully tested and we're going to go through the process of testing it. And when you deploy code out to the blockchain, it's not really source code. We write our source code and its very readable text in a code editor, but then we have to compile it to translate it into bytecode. The bytecode is the opcode that actually gets deployed out to the blockchain, and that's what the EVM runs. Like any language, we write code that we translate into a machine-readable format, and in order to do that, we have to abide by certain rules so that the computer understands it. So we have syntax rules and then we have semantics. Syntax rules are the rules that define how to write valid smart contracts. They're kind of like the rules of any language. If you speak in any language, such as English, there are certain rules you have to abide by. If you just throw words together in some weird order and they have no meaning, people are not going to understand what you're saying. It's the same thing in a programming language. You have to abide by certain rules so that the compiler will understand what you mean. If the compiler doesn't understand it, in other words, you use bad syntax, the program will not compile. Syntax defines what words, what characters, and what things are valid. So if a program compiles, it doesn't mean it's a perfect program because then you have semantics, it's what things mean. Even though a program is syntactically correct, it may be a stupid program and not do what it's supposed to do. So make sure that your programs compile, but then you test them to make sure they do what they do, all right? So that's two different phases of corrections in programs. Okay, let's take a look at the main smart contract elements. At the very high level, you've got a compiler version declarative, then you may have some comments. You really should have comments that describe what your program does. Then you may want to import external files, and then you define the actual smart contract and its contents, as well. All right, so let's start at the top, specifying a valid computer version. Solidity is still a very young language and it's constantly undergoing more and more changes, so we see new versions coming out all the time. The good part about that is that it's getting richer and richer. The bad part is that if you write code depending on one Solidity compiler version, and a new version comes out, that new version may conflict with your code. In other words, the new compiler may not properly compile your code. The new compilers often, or in some cases, will add more restrictions on how you write your code, and so your old code may not compile. So that's why we can tell the compiler at the very beginning, "Hey, this code should only compile with a version 0.5 or higher," or something like that. So we're going to see how to do that. We use the pragma directive that defines the Solidity compiler version or versions that'll compile a smart contract. Let's take a look at what that looks like. You've already seen it, but let's take a look back at our HelloWorld smart contract. So we're back to our HelloWorld smart contract. And if you recall, the very first line is the pragma directive. And we basically say pragma, give it a language, we're using Solidity, and then we're showing the minimum version. Now there's lots of different ways we can type this in, but in this case, we're going to say the caret, that first little character there, means that we have to have a minimum compiler version of 0.5.0 in order to compile this. So if we try to compile this with a lower version, it won't work, and actually the way the syntax works here, if we try to compile this with a 0.6 point something, it will not work either. We could put a dash here and put a range in so we could say 0.5.0 - 0.5.10, or something. So typically we just use a single minimum version, and this tells us that anything in the five range will be an acceptable compiler. The next thing that we want to be able to enter in our smart contracts would be comments, and there's two ways to enter comments in Solidity. One is a single-line comment. You always want to add as many comments as possible to communicate with other team members to explain what your program does. And honestly, I comment so that when I open a program six months later, I remember what I was thinking. So we can use single-line comments to start with two slashes. So I can say, "This is a demo smart contract." Now, we can also add comments onto lines, so let's say I go to the end of line seven and I just start typing "// this stores my string in a variable," and that gives me a comment that is on a single line. In other words, when I start typing the //, everything from there to the end of the line is a comment. Now, if you notice, I go back and my comment has a little yellow squiggly line under it. If I hover over it, it tells me, "Oh, you've got trailing white spaces." He doesn't like that. And sure enough, I've got an extra white space there. If I backspace over that, there it goes away. So anytime you see a warning, the yellow squiggly line is a warning. The red squiggly line would be an error, so you want to make sure you go look for those. So that's one type of comment. What if my comment is longer? What if I have, let's see, what if I have a very long comment that spans multiple lines? Well, we can do that as well. What I do is I start the comment with a special character, the /*, and I end with a */. And that makes it a comment. Of course, it still doesn't like the trailing spaces and that'll just make it look a little prettier, and we can have, you can open a comment on a single line, I kind of like to do it this way, make my comments on a single line, and then everything in between the slash star and star slash is a comment, and you can type anything you want there. So that's how we enter comments in Solidity. The next high level function in a smart contract is one that we don't see in the HelloWorld smart contract, and that is including code from other files. There's many times when you've already written a piece of code, and it has maybe some function definitions, or maybe it has variable definitions, and you don't want to re-type it over and over again, or copy paste. What you can do is you can simply say, "Include that other file over there." We're not going to show you that right now, but you'll see it when we start developing our token contract. Finally, once you have all of your precursors, you've got your comments, it describes what you're doing, you've imported any files, you've told it what compiler version to use, you're ready to actually define the guts of a smart contract, and that is the contract directive or the contract statement. Let's see what that looks like. All right, so we moved down, this contract is named HelloWorld.sol. In fact, that is the name of the file. So we see on line 11, the keyword "contract" followed by the name of the contract, and this should be the same name as the file. So it doesn't have to be, it's very convenient if it does do that, because you can actually define multiple contracts in one file. We're going to keep it simple for right now. So now we see that we are defining a contract named HelloWorld. We followed that with an open curly brace and then everything in between the open and the ending or closing curly brace would mean that is the body of our contract, and this is the guts of our smart contract. Very, very simple. We see the main elements except for the include already represented in our existing HelloWorld smart contract. So let's start from there, and let's add more and more layers so that you can learn more about the very powerful Solidity programming language to develop your own smart contracts.