Smart Contract Programming

One remembers the book written by Michael Hartl: Learn Enough Rails to be Dangerous. It's a great tutorial on how he teaches Rails. One can't say enough that one is copying the style to teach you guys on NEAR. So, here the first paragraph on this chapter is to credit his teachings, and style of approaches. You can check out his Learn Enough to be Dangerous website if there are anything you would like to learn about.

What we are going to do, is to go through several examples and let you see how the code are written, based on smart contracts already written and available in GitHub. The thinking goes like this: if you read and write enough smart contract, you can slowly pick up other smart contract on the way and learn it yourself, without having somebody explaining to you. Ultimately, the target of this course if you become a NEAR developer, and as a developer, reading and writing smart contract (especially reading) are usual plates of food. If you're already a developer, you already have the skill. One hopes to kickstart your journey, making it easier for you to read and understand code in the future.

Also, the code written will be somewhat different from the convention of most developers. Particularly, when one writes code, one tends to optimize for readability and understandability, so there may exist variables that are longer than usual (so it could be easily understandable), names that aren't following the convention (when convention doesn't explain much), for example. Nevertheless, one would put brackets around explaining what the original code uses so it eases you to read the code in the future).

Next is to choose the programming language. The frontend doesn't matter. One is a backend developer so any frontend requires one to learn, and we'll see which one to use as we go. For the backend, we'll use Rust (as opposed to AssemblyScript) (for personal reason which Rust's convention makes me happy while TypeScript not).

Though one have this weird fancy inconsistent tab space used, though, that might annoy you. In fact, one like to have 4 spaces for the first tab from the side, but subsequent tabs one like to have only 2 tabs, so you might find it weird to have this kind of tabbing. Let me show you an example (the cod e doesn't make much sense, btw).

fn some_fn():
    // four spacing at the beginning. 

    let name = "Rust";
    assert!(
      // two spacing thereafter
      name == "Rust"
    );

And it depends on how clutter the code is, one might use one spaces or two spaces between the functions or implementations for example. Sometimes it makes things easier to see with separators, so one might put some separators as well.

fn one_fn(): 
    // --snip--

// ===============Another section=============== //
fn another_fn():
    // --snip--

But it's not necessary always true that one have a convention. Basically, whatever that makes thing looks beautiful AND makes me happy is the way to go. :)

And there are some useful tips and tricks with Rust, which you can find here: NEAR SDK IO which teaches a lot on how to write smart contract in Rust, and what are some common stuffs that can be changed despite the convention to optimize for contract size, etc. The page it links is just one of the page, navigate to the other pages yourself (note if you have the page open half-screen, the table of content will appear on the bottom right of your screen compared to top left when you open the page semi-fullscreen).

Notes

Note that one write in this way as it makes one happy. You DO NOT have to follow the style of one's writing. If you have your own programming style, you're welcome to adapt to how you usually do things, it makes you happy anyways!