OpenZeppelin coding standard

abcoathup · March 12, 2021, 3:34am

Welcome to the community

There are style guidelines for OpenZeppelin Contracts:

OpenZeppelin/openzeppelin-contracts/blob/master/GUIDELINES.md#style-guidelines

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

OpenZeppelin Contracts contributions are reviewed by the maintainers of the repository. Linters are also used for contributions:

github.com

OpenZeppelin/openzeppelin-contracts/blob/master/CONTRIBUTING.md

Contributing to OpenZeppelin Contracts
=======

We really appreciate and value contributions to OpenZeppelin Contracts. Please take 5' to review the items listed below to make sure that your contributions are merged as soon as possible.

## Contribution guidelines

Smart contracts manage value and are highly vulnerable to errors and attacks. We have very strict [guidelines], please make sure to review them!

## Creating Pull Requests (PRs)

As a contributor, you are expected to fork this repository, work on your own fork and then submit pull requests. The pull requests will be reviewed and eventually merged into the main repo. See ["Fork-a-Repo"](https://help.github.com/articles/fork-a-repo/) for how this works.

## A typical workflow

1) Make sure your fork is up to date with the main repository:

```
cd openzeppelin-contracts
git remote add upstream https://github.com/OpenZeppelin/openzeppelin-contracts.git

This file has been truncated. show original

Multiple people have contributed to OpenZeppelin Contracts including the current maintainers.

If you have feedback on specific contracts (or for OpenZeppelin Contracts in general) you can post in the forum where the community can respond.

We are looking for feedback on OpenZeppelin Contracts 4.0 Beta.
Feedback from the community has been incorporated into the Beta.

Topic		Replies	Views
Built with OpenZeppelin - share the love General	1	2733	March 2, 2020
Shape the future of Contracts: community poll :white_check_mark: Contracts	1	272	December 14, 2023
Does code comply with OpenZeppelin license and copyright terms? Contracts erc20	4	2091	November 25, 2020
We're writing new guides, help us improve them! General	14	3341	June 14, 2019
OpenZeppelin Smart Contract Design Rationale Contracts	5	833	May 12, 2020

OpenZeppelin coding standard

Related topics