summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorosjuga <43299093+osjuga@users.noreply.github.com>2019-12-07 07:19:18 -0500
committerfauxpark <fauxpark@gmail.com>2019-12-07 23:19:18 +1100
commitf275ffbdfc1cbd1965cd3546b45a7838012321da (patch)
tree548dba9d1d37dd236dfee8e97ebca5088c6989c6
parent36a6e269bfff8b557a92e3c5e7a4a104d0dfe5f7 (diff)
Minor grammar and filename fixes in docs (#7559)
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
-rw-r--r--docs/coding_conventions_c.md2
-rw-r--r--docs/coding_conventions_python.md2
-rw-r--r--docs/feature_haptic_feedback.md2
-rw-r--r--docs/feature_rgb_matrix.md2
4 files changed, 4 insertions, 4 deletions
diff --git a/docs/coding_conventions_c.md b/docs/coding_conventions_c.md
index 08994bfbb7..16e28b2884 100644
--- a/docs/coding_conventions_c.md
+++ b/docs/coding_conventions_c.md
@@ -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
* Use them liberally to explain why particular decisions were made.
* 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.
* 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)`
diff --git a/docs/coding_conventions_python.md b/docs/coding_conventions_python.md
index 694aa38cfc..9dd95e4b73 100644
--- a/docs/coding_conventions_python.md
+++ b/docs/coding_conventions_python.md
@@ -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
* Use them liberally to explain why particular decisions were made.
* 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.
* 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.
diff --git a/docs/feature_haptic_feedback.md b/docs/feature_haptic_feedback.md
index 2273633227..ff7337a51a 100644
--- a/docs/feature_haptic_feedback.md
+++ b/docs/feature_haptic_feedback.md
@@ -2,7 +2,7 @@
## 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`
diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md
index 5b834a99d5..5695acc508 100644
--- a/docs/feature_rgb_matrix.md
+++ b/docs/feature_rgb_matrix.md
@@ -286,7 +286,7 @@ You can disable a single effect by defining `DISABLE_[EFFECT_NAME]` in your `con
## 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: