Skip to content

CODING_STYLE.md

Latest commit

 

History

History
110 lines (64 loc) · 2.98 KB

CODING_STYLE.md

File metadata and controls

110 lines (64 loc) · 2.98 KB
Raw

Intro

This guide is clearly inspired by the official FlipperZero Firmware Coding Style

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.

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.

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

Code Formatting

Note: This project does not follow the same formatting rules as the official Flipper Zero firmware.

Instead, we use GNU indent to format the C source code consistently.

Auto-formatting your code

To automatically format your C files, run:

indent -kr -ts1

Tip: You can set up a Git pre-commit hook to automatically format your code each time you commit. This ensures consistent style across your project

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