Code of Conduct

The code we trust

• We aim to keep our deployed contracts slim in size to maintain minimalism.

• We opt for clear and concise words over excessive commenting to improve readability.

• We believe that each contract should serve a simple purpose well for modularity.

• We aim to adhere to design patterns such as loose coupling and tight cohesion.

• We avoid, whenever possible, code smells like the plague.

Why?

There are many reasons to why we follow these guidelines. Let's sum it up by giving an analogy:

Building blocks "A huge construct broken down should have identifiable pieces. Each having a clearly defined purpose and goal; a reason for existence. Cemented together they should support one another without conflict nor should it let the whole foundation crumble if one were to turn out chipped, cracked or ruined."

Ah, so vague...

...to make it more concrete: Solidity's Immutability makes it hard to change things around or squash bugs whenever grave errors or tiny mistakes are found. These rules try to minimize such potential outcomes by making simplicity the central theme in everything we do.

Simplicity "A simple contract serving a clearly defined purpose well is easier to debug and less likely to fail than one that is in charge of a lot."

NOTE: however, there are times when we are forced to make compromises, since following these rules does not necessarily mean going for the most cost-efficient route.

An example of this would be the copy-and-pasting of logic, but slightly different, into another function just to minimize the amount of gas the contract call uses. In the coding community the act of duplicating code is seen as a notorious code smell, but could sometimes save you a ton of gas in Solidity.