Add recommendations for coding styles (#64)

* Add recommendations for coding styles
* Fix ordering of bullet points
* Add more info about names and explanation for jinja notation
* Apply suggestions from review, condensing repetitive items and improving verbiage
* Reduce redunant rules, add additional info, and adopt review suggestions
* Remove capitalization recommendation

coding_style/README.adoc

@@ -23,10 +23,13 @@ Rationale:: even when Ansible currently allows names that are not valid identifi
 Making all names valid identifiers will avoid encountering problems in the future. Dictionary keys that are not valid identifiers are also less intuitive to use in Jinja2 (a dot in a dictionary key would be particularly confusing).
 ====
 
-* Use mnemonic and descriptive names and do not shorten more than necessary.
+* Use mnemonic and descriptive names that are human-readable and do not shorten more than necessary.
   A pattern `object[_feature]_action` has proven useful as it guarantees a proper sorting in the file system for roles and playbooks.
   Systems support long identifier names, so use them!
 * Avoid numbering roles and playbooks, you'll never know how they'll be used in the future.
+* Name all tasks, plays, and task blocks to improve readability.
+* Write task names in the imperative (e.g. "Ensure service is running"), this communicates the action of the task.
+* Avoid abbreviations in names, or use capital letter for abbreviations where it cannot be avoided.
 
 == YAML and Jinja2 Syntax
 
@@ -161,6 +164,27 @@ Rationale:: https://yaml.org/type/bool.html[YAML 1.1] allows all variants wherea
   your task will likely need options such as `changed_when:` and maybe `check_mode:`).
 * Anytime `command` or `shell` modules are used, add a comment in the code with justification to help with future maintenance.
 * Use the `| bool` filter when using bare variables (expressions consisting of just one variable reference without any operator) in `when`.
+* Break complex task files down into discrete parts.
++
+[%collapsible]
+====
+Rationale::
+Task files that are very or and/or contain highly nested blocks are difficult to maintain.
+Breaking a large or complex task file into multiple discrete files makes it easier to read and understand what is being done in each part.
+====
+
+* Use bracket notation instead of dot notation for value retrieval (e.g. `item['key']` vs. `item.key`)
++
+[%collapsible]
+====
+Rationale::
+Dot notation will fail in some cases (such as when a variable name includes a hyphen) and it's better to stay consistent than to switch between the two options within a role or playbook.
+Additionally, some key names collide with attributes and methods of Python dictionaries such as `count`, `copy`, `title`, and others (refer to the https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#referencing-key-value-dictionary-variables[Ansible User Guide] for an extended list)
+
+Example::
+This https://blog.networktocode.com/post/Exploring-Jinja-Variable-Syntax-in-Ansible[post] provdes an excellent demonstration of how using dot notation syntax can impact your playbooks.
+====
+
 * Do not use `meta: end_play`.
 +
 [%collapsible]