summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/best_practices_guide.adoc14
-rw-r--r--docs/style_guide.adoc2
2 files changed, 8 insertions, 8 deletions
diff --git a/docs/best_practices_guide.adoc b/docs/best_practices_guide.adoc
index 267aa850d..e9d904965 100644
--- a/docs/best_practices_guide.adoc
+++ b/docs/best_practices_guide.adoc
@@ -52,11 +52,11 @@ If mode lines for other editors are needed, please open a GitHub issue.
=== Method Signatures
'''
-[[When-adding-a-new-paramemter-to-an-existing-method-a-default-value-SHOULD-be-used]]
+[[When-adding-a-new-parameter-to-an-existing-method-a-default-value-SHOULD-be-used]]
[cols="2v,v"]
|===
-| <<When-adding-a-new-paramemter-to-an-existing-method-a-default-value-SHOULD-be-used, Rule>>
-| When adding a new paramemter to an existing method, a default value SHOULD be used
+| <<When-adding-a-new-parameter-to-an-existing-method-a-default-value-SHOULD-be-used, Rule>>
+| When adding a new parameter to an existing method, a default value SHOULD be used
|===
The purpose of this rule is to make it so that method signatures are backwards compatible.
@@ -76,7 +76,7 @@ def add_person(first_name, last_name, age=None):
=== PyLint
-http://www.pylint.org/[PyLint] is used in an attempt to keep the python code as clean and as managable as possible. The build bot runs each pull request through PyLint and any warnings or errors cause the build bot to fail the pull request.
+http://www.pylint.org/[PyLint] is used in an attempt to keep the python code as clean and as manageable as possible. The build bot runs each pull request through PyLint and any warnings or errors cause the build bot to fail the pull request.
'''
[[PyLint-rules-MUST-NOT-be-disabled-on-a-whole-file]]
@@ -194,7 +194,7 @@ The purpose of this rule is to make it easy to include custom modules in our pla
| Parameters to Ansible modules SHOULD use the Yaml dictionary format when 3 or more parameters are being passed
|===
-When a module has several parameters that are being passed in, it's hard to see exactly what value each parameter is getting. It is preferred to use the Ansible Yaml syntax to pass in parameters so that it's more clear what values are being passed for each paramemter.
+When a module has several parameters that are being passed in, it's hard to see exactly what value each parameter is getting. It is preferred to use the Ansible Yaml syntax to pass in parameters so that it's more clear what values are being passed for each parameter.
.Bad:
[source,yaml]
@@ -222,7 +222,7 @@ When a module has several parameters that are being passed in, it's hard to see
| Parameters to Ansible modules SHOULD use the Yaml dictionary format when the line length exceeds 120 characters
|===
-Lines that are long quickly become a wall of text that isn't easily parsable. It is preferred to use the Ansible Yaml syntax to pass in parameters so that it's more clear what values are being passed for each paramemter.
+Lines that are long quickly become a wall of text that isn't easily parsable. It is preferred to use the Ansible Yaml syntax to pass in parameters so that it's more clear what values are being passed for each parameter.
.Bad:
[source,yaml]
@@ -432,7 +432,7 @@ This is very useful when developing and debugging new tasks. It can also signifi
[[Ansible-Roles-SHOULD-be-named-like-technology_component_subcomponent]]
[cols="2v,v"]
|===
-| [[Ansible-Roles-SHOULD-be-named-like-technology_component_subcomponent, Rule]]
+| <<Ansible-Roles-SHOULD-be-named-like-technology_component_subcomponent, Rule>>
| Ansible Roles SHOULD be named like technology_component[_subcomponent].
|===
diff --git a/docs/style_guide.adoc b/docs/style_guide.adoc
index 72eaedcf9..2c2cb8610 100644
--- a/docs/style_guide.adoc
+++ b/docs/style_guide.adoc
@@ -103,7 +103,7 @@ Ansible role variables are defined as variables contained in (or passed into) a
[cols="2v,v"]
|===
| <<Role-variables-MUST-have-a-prefix-of-atleast-3-characters-See.below.for.specific.naming.rules, Rule>>
-| Role variables MUST have a prefix of atleast 3 characters. See below for specific naming rules.
+| Role variables MUST have a prefix of at least 3 characters. See below for specific naming rules.
|===
==== Role with 3 (or more) words in the name