Ansible Coding and Configuration Guidelines

Ansible coding and configuration guidelines.

Prefixing Variables and Separating Words in Ansible

Prefix public role variables with the role name, internal role variables with __role_name_, inventory-only variables with a project prefix, and separate words with underscores in Ansible variable names.

Using item and loop_var in Ansible Loops

Use item as the default loop variable. Reserve loop_control.loop_var for cases where item would collide across loop boundaries, such as nested loops and include_tasks.

Dot Notation vs Bracket Notation in Ansible and Jinja

Prefer dot notation for fixed keys. Use bracket notation only when dot notation cannot express the access safely or correctly.

Avoid Hardcoding Download URLs and Paths in Tasks

Define download URLs and paths in variables instead of hardcoding them in tasks.

Using Labels in Ansible Loops

Use loop_control.label to keep Ansible loop output short and readable when a loop iterates over dictionaries or other large values.

Slashes vs Backslashes When Targeting MS Windows Hosts

When targeting MS Windows hosts, use slashes for all paths. Convert to backslashes only if necessary.

Using Tags in Ansible Roles

Use a consistent tagging structure in Ansible roles to make playbook runs more targeted and maintainable.

Dictionary Merging in Ansible Inventories

Use dictionary merging deliberately and predictably in Ansible inventories to keep overrides maintainable.

Keep Variable and Identifier Names Short and Consistent

Prefer short, consistent names that reduce noise without making variables or identifiers unclear.

Import Unless: Prefer Static Reuse in Ansible

Prefer import_tasks, import_role, or the play-level roles section for reusable Ansible content. Use include_tasks or include_role only when you need dynamic runtime behavior.



Last modified September 10, 2026: guidelines coding C2-1630 C2-1628 C2-1629 (1f6a9b9)