mirrors/qmk_firmware
1
0
Fork 1
mirror of https://github.com/qmk/qmk_firmware synced 2024-11-19 03:36:28 +00:00
Code Issues Projects Releases Packages Wiki Activity

Update our style guide (#5500)

Browse source 
* Update our style guide

* Clarify muiltple condition ifs

* update the ifdef section
This commit is contained in:
skullydazed 2019-04-18 15:59:51 -07:00 committed by GitHub
parent 7a1086e405
commit 068571b9fe
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 11 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
.clang-format
View file

@ -20,7 +20,7 @@ SortIncludes: 'false'
SpaceBeforeAssignmentOperators: 'true' SpaceBeforeAssignmentOperators: 'true'
SpaceBeforeParens: ControlStatements SpaceBeforeParens: ControlStatements
SpaceInEmptyParentheses: 'false' SpaceInEmptyParentheses: 'false'
TabWidth: '2' TabWidth: '4'
UseTab: Never UseTab: Never
... ...

2
.editorconfig
View file

@ -5,7 +5,7 @@ root = true
[*] [*]
indent_style = space indent_style = space
indent_size = 2 indent_size = 4
# We recommend you to keep these unchanged # We recommend you to keep these unchanged
charset = utf-8 charset = utf-8

10
docs/contributing.md
View file

@ -56,7 +56,7 @@ Never made an open source contribution before? Wondering how contributions work
Most of our style is pretty easy to pick up on, but right now it's not entirely consistent. You should match the style of the code surrounding your change, but if that code is inconsistent or unclear use the following guidelines: Most of our style is pretty easy to pick up on, but right now it's not entirely consistent. You should match the style of the code surrounding your change, but if that code is inconsistent or unclear use the following guidelines:
* We indent using two spaces (soft tabs) * We indent using four (4) spaces (soft tabs)
* We use a modified One True Brace Style * We use a modified One True Brace Style
* Opening Brace: At the end of the same line as the statement that opens the block * Opening Brace: At the end of the same line as the statement that opens the block
* Closing Brace: Lined up with the first character of the statement that opens the block * Closing Brace: Lined up with the first character of the statement that opens the block
@ -71,6 +71,14 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
* If you not sure if a comment is obvious, go ahead and include it. * If you not sure if a comment is obvious, go ahead and include it.
* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns. * In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
* We use `#pragma once` at the start of header files rather than old-style include guards (`#ifndef THIS_FILE_H`, `#define THIS_FILE_H`, ..., `#endif`) * We use `#pragma once` at the start of header files rather than old-style include guards (`#ifndef THIS_FILE_H`, `#define THIS_FILE_H`, ..., `#endif`)
* We accept both forms of preprocessor if's: `#ifdef DEFINED` and `#if defined(DEFINED)`
* If you are not sure which to prefer use the `#if defined(DEFINED)` form.
* Do not change existing code from one style to the other, except when moving to a multiple condition `#if`.
* Do not put whitespace between `#` and `if`.
* When deciding how (or if) to indent directives keep these points in mind:
* Readability is more important than consistency.
* Follow the file's existing style. If the file is mixed follow the style that makes sense for the section you are modifying.
* When choosing to indent you can follow the indention level of the surrounding C code, or preprocessor directives can have their own indent level. Choose the style that best communicates the intent of your code.
Here is an example for easy reference: Here is an example for easy reference: