Style Guide - esherproject/esher-core GitHub Wiki

DRAFT -- Esher Coding Style / Guide

Standardization

This Cording Style Guide are specific to Esher-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.

Scoping

Classes

Functions

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

Exception Rules