Skip to content

Style Guide

Jump to bottom
serdrdoor edited this page Aug 31, 2021 · 3 revisions

DRAFT -- Graphene Coding Style / Guide

Standardization

This Cording Style Guide are specific to Graphene-Core codebase. It will save time to the programmer and reviewer.

Discussion

General

  • Use FC_ASSERT instead of assert (reason: assert() checks are executed conditionally depending on compile-time settings, which endangers consensus)
  • Use using instead of typedef

Formatting

  • Maximum line length: 118 (*That's what you can see on github without side-scrolling)
  • newline at the end of each file.
  • Avoid multiple empty new lines in code, in general 1 empty line is enough to separate blocks of code.
  • Long calls, definitions or declarations are recommended to use this style: 496c622
  • TBD spaces

Discussion - spaces and padding

  • 3 spaces indentation
  • 4 spaces of indentation, and do away with padding the insides of parentheses.
  • for function and method calls, there is no space between function name and opening parenthesis
  • for control statements there is a space between statement and opening parenthesis

Suggestions

  • We should
    • come to a consensus regarding formatting rules
    • find a tool that can do it automatically
    • make a big whitespace-only change

Comments

  • Remove commented code. Comments can be made when code seems not enough to explain an idea, that comments are generally used in test cases and explain in plain English what is happening. Commented code should not be submitted, just delete it.

Naming

  • Method names should be all lowercase with "_" as word separator: #1271 (comment)

Scoping

  • lambda expressions must capture variables explicitly if what you need is not too many.
  • In a huge refactoring please do it in small steps in individual commits that are easily verifiable. This makes the reviewer life a bit easier. - From: #1413 (comment)
  • Avoid global variables. From #1324 (comment)

Classes

Functions

  • When defining a function: { should always be in a new line.

Exception Rules

Architecture

  • Create/modify/delete of the database inside operation evaluator must be done in do_apply and never in do_evaluate - From #1449 (comment)
  • When new fields are added or removed to objects; a bump of the database is needed. From: #1449 (review)

Pull Requests

  • Pull requests should add/modify/delete the minimum amount code possible to develop 1 and only 1 feature or concept. From #1467 - Pull doing several stuff at once.
  • Pull requests in bitshares can only be made against 2 branches: develop if there is a non consensus related change or hardfork if it is modifying consensus.
Clone this wiki locally