unleashed-firmware/CODING_STYLE.md
Petr Portnov | PROgrm_JARvis 75354ec5ba
fix: make dialog_file_browser_set_basic_options initialize all fields (#2756)
* fix: make `dialog_file_browser_set_basic_options` initialize all fields
* fix(GH-2756): use alternative test for `test_dialog_file_browser_set_basic_options_should_init_all_fields`

Co-authored-by: Aleksandr Kutuzov <alleteam@gmail.com>
2023-06-27 18:46:04 +09:00

102 lines
2.8 KiB
Markdown

# 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:
- https://www.kernel.org/doc/html/v4.10/process/coding-style.html
- https://docs.unrealengine.com/en-US/Programming/Development/CodingStandard
- https://webkit.org/code-style-guidelines/
# 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](https://pypi.org/project/black/) to reformat source code before commit