Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grammatical error correction in content #740

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Grammatical error correction in content #740

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions en/5/13-comments.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -485,7 +485,7 @@ The Solidity code for our zombie game is finally finished!

In the next lessons, we'll look at how to deploy the code to Ethereum, and how to interact with it with Web3.js.

But one final thing before we let you go in Lesson 5: Let's talk about **commenting your code**.
But one final thing before we let you go in Lesson 5: Let's talk about **commenting on your code**.

## Syntax for comments

Expand All @@ -503,7 +503,7 @@ Thus we also have multi-line comments:

```
contract CryptoZombies {
/* This is a multi-lined comment. I'd like to thank all of you
/* This is a multi-line comment. I'd like to thank all of you
who have taken your time to try this programming course.
I know it's free to all of you, and it will stay free
forever, but we still put our heart and soul into making
Expand All @@ -521,7 +521,7 @@ contract CryptoZombies {
}
```

In particular, it's good practice to comment your code to explain the expected behavior of every function in your contract. This way another developer (or you, after a 6 month hiatus from a project!) can quickly skim and understand at a high level what your code does without having to read the code itself.
In particular, it's good practice to comment on your code to explain the expected behavior of every function in your contract. This way another developer (or you, after a 6 month hiatus from a project!) can quickly skim and understand at a high level what your code does without having to read the code itself.

The standard in the Solidity community is to use a format called **_natspec_**, which looks like this:

Expand Down