Skip to content

Style Guide

Peter Conrad edited this page Apr 3, 2019 · 2 revisions

DRAFT -- BitShares Coding Style / Guide


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



  • 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


  • 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


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


  • 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.


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


  • 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)



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

Exception Rules


  • 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