Skip to content

Latest commit

 

History

History
101 lines (62 loc) · 2.81 KB

CODING_STYLE.md

File metadata and controls

101 lines (62 loc) · 2.81 KB
Raw

Intro

Nice to see you reading this document, we really appreciate it.

As all documents of this kind it's unable to cover everything. But it will cover general rules that we are enforcing on PR review.

Also, we already have automatic rules checking and formatting, but it got its limitations and this guide is still mandatory.

Some part of this project do have its own naming and coding guides. For example: assets. Take a look into ReadMe.md in assets folder for more details.

Also, 3rd party libraries are none of our concern.

And yes, this set is not final and we are open to discussion. If you want to add/remove/change something here please feel free to open new ticket.

Inspiration

Our guide is inspired by, but not claiming to be compatible with:

General rules

Readability and Simplicity first

Code we write is intended to be public. Avoid one-liners from hell and keep code complexity under control. Try to make code self-explanatory and add comments if needed. Leave references to standards that you are implementing. Use project wiki to document new/reverse engineered standards.

Variable and function names must clearly define what it's doing

It's ok if it will be long, but it should clearly state what it's doing, without need to dive into code. This also applies to function/method's code. Try to avoid one letter variables.

Encapsulation

Don't expose raw data, provide methods to work with it. Almost everything in flipper firmware is built around this concept.

C coding style

  • Tab is 4 spaces
  • Use ./fbt format to reformat source code and check style guide before commit

Naming

Type names are PascalCase

Examples:

FuriHalUsb
Gui
SubGhzKeystore

Functions are snake_case

furi_hal_usb_init
gui_add_view_port
subghz_keystore_read

File and Package name is a prefix for it's content

This rule makes easier to locate types, functions and sources.

For example:

We have abstraction that we call SubGhz Keystore, so there will be: file subghz_keystore.h we have type SubGhzKeystore and function subghz_keystore_read.

File names

  • Directories: ^[0-9A-Za-z_]+$
  • File names: ^[0-9A-Za-z_]+\.[a-z]+$
  • File extensions: [ ".h", ".c", ".cpp", ".cxx", ".hpp" ]

Enforced by linter.

Standard function/method names

Suffixes:

  • alloc - allocate and init instance. C style constructor. Returns pointer to instance.
  • free - de-init and release instance. C style destructor. Takes pointer to instance.

C++ coding style

Work In Progress. Use C style guide as a base.

Python coding style

  • Tab is 4 spaces
  • Use black to reformat source code before commit