Introduce yourself here!

abcoathup · June 18, 2019, 8:57am

Wecome @piedup to the community forum!

I have checked out sorare previously. I thought I already had a sorare card, but looks like I haven’t purchased one yet.

OpenZeppelin repository is a great place to learn about Solidity best practices.

The Guidelines and Code Style documents are great reads:

github.com

OpenZeppelin/openzeppelin-solidity/blob/master/GUIDELINES.md

Design Guidelines
=======

These are some global design goals in OpenZeppelin.

#### D0 - Security in Depth
We strive to provide secure, tested, audited code. To achieve this, we need to match intention with function. Thus, documentation, code clarity, community review and security discussions are fundamental.

#### D1 - Simple and Modular
Simpler code means easier audits, and better understanding of what each component does. We look for small files, small contracts, and small functions. If you can separate a contract into two independent functionalities you should probably do it.

#### D2 - Naming Matters

We take our time with picking names. Code is going to be written once, and read hundreds of times. Renaming for clarity is encouraged.

#### D3 - Tests

Write tests for all your code. We encourage Test Driven Development so we know when our code is right. Even though not all code in the repository is tested at the moment, we aim to test every line of code in the future.

#### D4 - Check preconditions and post-conditions

This file has been truncated. show original

github.com

OpenZeppelin/openzeppelin-solidity/blob/master/CODE_STYLE.md

# Code Style

We value clean code and consistency, and those are prerequisites for us to
include new code in the repository. Before proposing a change, please read this
document and take some time to familiarize yourself with the style of the
existing codebase.

## Solidity code

In order to be consistent with all the other Solidity projects, we follow the
[official recommendations documented in the Solidity style guide](http://solidity.readthedocs.io/en/latest/style-guide.html).

Any exception or additions specific to our project are documented below.

### Naming

* Try to avoid acronyms and abbreviations.

* All state variables should be private.

This file has been truncated. show original

I would recommend (if you haven’t already) linting contracts and tests, OpenZeppelin style is good to follow:

github.com

OpenZeppelin/openzeppelin-solidity/blob/master/.solhint.json

{
  "extends": "solhint:recommended",
  "rules": {
    "indent": ["error", 4],
    "func-order": "off",
    "bracket-align": "off",
    "compiler-fixed": "off",
    "no-simple-event-func-name": "off",
    "separate-by-one-line-in-contract": "off",
    "two-lines-top-level-separator": "off",
    "mark-callable-contracts": "off",
    "compiler-version": ["error", "^0.5.0"]
  }
}

github.com

OpenZeppelin/openzeppelin-solidity/blob/master/.eslintrc

{
  "extends" : [
    "standard",
    "plugin:promise/recommended",
  ],
  "plugins": [
    "mocha-no-only",
    "promise",
  ],
  "env": {
    "browser" : true,
    "node"    : true,
    "mocha"   : true,
    "jest"    : true,
  },
  "globals" : {
    "artifacts": false,
    "contract": false,
    "assert": false,
    "web3": false,

This file has been truncated. show original

100% code coverage for your tests is a great target.

Would appreciate if you have any suggestions for Guides and Tutorials requests that the community needs, that would be great.

Topic		Replies	Views
New category names! Meta	0	856	July 19, 2019
What are you working on? General	43	6514	November 21, 2021
Looking Freelancer Developer Wanted	2	420	May 4, 2021
Community Recognition Hall General	10	1372	April 15, 2020
Leave feedback here! Meta	14	2810	May 21, 2019

Introduce yourself here!

Related Topics