varl/qmk_firmware
1
0
Fork 0
forked from forks/qmk_firmware
Code Pull requests Activity

Minor grammar and filename fixes in docs (#7559)

Browse source 
Grammar in coding_conventions_c.md and coding_conventions_python.md

`rule.mk` to `rules.mk` in feature_haptic_feedback.md and feature_rgb_matrix.md
This commit is contained in:
osjuga 2019-12-07 07:19:18 -05:00 committed by fauxpark
parent 36a6e269bf
commit f275ffbdfc
4 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/coding_conventions_c.md
View file

@ -14,7 +14,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
* Think of them as a story describing the feature * Think of them as a story describing the feature
* Use them liberally to explain why particular decisions were made. * Use them liberally to explain why particular decisions were made.
* Do not write obvious comments * Do not write obvious comments
* If you not sure if a comment is obvious, go ahead and include it. * If you're 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)` * We accept both forms of preprocessor if's: `#ifdef DEFINED` and `#if defined(DEFINED)`

2
docs/coding_conventions_python.md
View file

@ -8,7 +8,7 @@ Most of our style follows PEP8 with some local modifications to make things less
* Think of them as a story describing the feature * Think of them as a story describing the feature
* Use them liberally to explain why particular decisions were made. * Use them liberally to explain why particular decisions were made.
* Do not write obvious comments * Do not write obvious comments
* If you not sure if a comment is obvious, go ahead and include it. * If you're not sure if a comment is obvious, go ahead and include it.
* We require useful docstrings for all functions. * We require useful docstrings for all functions.
* 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.
* Some of our practices conflict with the wider python community to make our codebase more approachable to non-pythonistas. * Some of our practices conflict with the wider python community to make our codebase more approachable to non-pythonistas.

2
docs/feature_haptic_feedback.md
View file

@ -2,7 +2,7 @@
## Haptic feedback rules.mk options ## Haptic feedback rules.mk options
The following options are currently available for haptic feedback in `rule.mk`: The following options are currently available for haptic feedback in `rules.mk`:
`HAPTIC_ENABLE += DRV2605L` `HAPTIC_ENABLE += DRV2605L`

2
docs/feature_rgb_matrix.md
View file

@ -286,7 +286,7 @@ You can disable a single effect by defining `DISABLE_[EFFECT_NAME]` in your `con
## Custom RGB Matrix Effects ## Custom RGB Matrix Effects
By setting `RGB_MATRIX_CUSTOM_USER` (and/or `RGB_MATRIX_CUSTOM_KB`) in `rule.mk`, new effects can be defined directly from userspace, without having to edit any QMK core files. By setting `RGB_MATRIX_CUSTOM_USER` (and/or `RGB_MATRIX_CUSTOM_KB`) in `rules.mk`, new effects can be defined directly from userspace, without having to edit any QMK core files.
To declare new effects, create a new `rgb_matrix_user/kb.inc` that looks something like this: To declare new effects, create a new `rgb_matrix_user/kb.inc` that looks something like this: