# Survey on various Ansible Style questions (CfgMgmtCamp follow-up)

**URL:** <https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302>\
**Category:** Project Discussions\
**Tags:** cfgmgmgtcamp, ansible-lint, ansible-core\
**Created:** [February 8, 2026, 12:15pm UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302 "2026-02-08T12:15:06Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![volenbovsky](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/volenbovsky/32/10309_2.png) [@volenbovsky](https://forum.ansible.com/u/volenbovsky)\
**Post date:** [February 8, 2026, 12:15pm UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/1 "2026-02-08T12:15:07Z")

</div>

Hi everyone

following CfgMgmtCamp let me ask the community on certain style questions for Ansible.

In case you already answered in LimeSurvey or in person on the questions - please do not answer on all questions except questions 7, 8,9 below 🙂 - these questions are the are new ones

Some additional info on questions below:

1. It is possible to use “dot notation” for dictionaries in many cases. The bracket notation is mandatory the variables use reserved names; for variables that use special characters;

Let’s say that because it is widespread ansible\_facts will still use bracket notation  
`ansible_facts['hostname']`.

Reference:

> **[add - Using variables — Ansible Community Documentation](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_variables.html#referencing-key-value-dictionary-variables)**
>
> A dictionary stores data in key-value pairs. Usually, you use dictionaries to store related data, such as the information contained in an ID or a user profile.

1. it is possible to avoid quotes for most of the strings in YAML, the exceptions are:

If the string contains (e.g. `:` , `{` , `}` , `[` , `]` , `,` , `&` , `*` , `#` , `?` , `|` , `-` , `<` , `>` , `=` , `!` , `%` , `@` , `\` ).  
and  
If the value starts with characters like `!`, `&`, or `#`.

Additional reading:

> <https://stackoverflow.com/questions/19109912/do-i-need-quotes-for-strings-in-yaml/69850618#69850618>

> **[YAML Best Practices - YS — YAML Done Wisely](https://yamlscript.org/blog/2025-07-20/yaml-best-practices/)**
>
> Program in YAML — Code is Data

**Survey**

_Poll ([view on site](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/1))_

_Poll ([view on site](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/1))_

_Poll ([view on site](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/1))_

_Poll ([view on site](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/1))_

_Poll ([view on site](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/1))_

_Poll ([view on site](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/1))_

_Poll ([view on site](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/1))_

_Poll ([view on site](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/1))_

_Poll ([view on site](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/1))_

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [February 8, 2026, 2:30pm UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/2 "2026-02-08T14:30:18Z")

</div>

Regarding `meta/main.yml` in roles in collections: I think there was a time when galaxy-importer rejected a collection that had a role without this file. That might have changed though… This is I think the only reason why I maintain this file for some of my collections that have roles.

---

<div class="post-metadata">

**Author:** ![kks](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kks/32/10352_2.png) [@kks](https://forum.ansible.com/u/kks)\
**Post date:** [February 8, 2026, 8:05pm UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/3 "2026-02-08T20:05:20Z")

</div>

> [@volenbovsky](#):
>
> Q7. What is the preferred notation for lists and dictionaries?

I always use ansible (yaml) style notation especially for lists and dictionaries. If lists are changing, it looks nice in git diffs.

> [@volenbovsky](#):
>
> Q2. Is it good practice to prefix internal variables with double underscores (`__`) and use r\_ prefix for variables used in “register” task attribute?

Wonder what do you consider internal variable of the role in this context?

I think that having anything coded in the name is an antipattern and should not be used. My understanding is that this practice is coming from the fact that there is no go to definition and go to references functionality in ansible language server for variables (and for roles). One cannot simply check definition of a variable.

---

<div class="post-metadata">

**Author:** ![bvitnik](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bvitnik/32/4132_2.png) [@bvitnik](https://forum.ansible.com/u/bvitnik)\
**Post date:** [February 9, 2026, 12:15am UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/4 "2026-02-09T00:15:36Z")

</div>

> [@volenbovsky](#):
>
> Q6. What are the verb(s) that should be used within a task name?

There is a topic I’ve opened for the same question (+ pool) and some additional alternatives proposed for task naming:

> [@On the philosophy of task naming](https://forum.ansible.com/t/on-the-philosophy-of-task-naming/45096):
>
> Sometimes I don’t think to much about it so I end up using different styles of task naming in the same project, for example: Install the package (imperative form) Installation of the package (noun form) Installing the package (progressive form) One ought to stick to the one form… but which one? ChatGPT is insisting that imperative form i.e “Install the package” is the best one, the recommended one and the most used one. While it makes all the sense if you are reading the code, I don’t see muc…

---

<div class="post-metadata">

**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\
**Post date:** [February 9, 2026, 9:32am UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/5 "2026-02-09T09:32:16Z")

</div>

> Q2. Is it good practice to prefix internal variables with double underscores (`__` ) and use r\_ prefix for variables used in “register” task attribute?

When writing a role which requires an internal variable, I usually follow the PEP 8 Style guide for specifying variables with a single leading underscore. Taken from: [PEP 8 – Style Guide for Python Code | peps.python.org](https://peps.python.org/pep-0008/)

> `_single_leading_underscore` : weak “internal use” indicator.

```yaml
---
# defaults/main.yml
_my_internal_var:
  - example

```

---

<div class="post-metadata">

**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\
**Post date:** [February 9, 2026, 9:35am UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/6 "2026-02-09T09:35:51Z")

</div>

Adding to this, just thought you might want to take a look at the Red Hat Community of Practice styling guide: [Good Practices for Ansible - GPA](https://redhat-cop.github.io/automation-good-practices/#_roles_good_practices_for_ansible)

As I’m reading through this I can see that my preference above contradicts that of the guide! 🤭

#### 3.1.4. Naming parameters

> Moreover, internal variables (those that are not expected to be set by users) are to be prefixed by two underscores: `__foo_variable` .

---

<div class="post-metadata">

**Author:** ![volenbovsky](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/volenbovsky/32/10309_2.png) [@volenbovsky](https://forum.ansible.com/u/volenbovsky)\
**Post date:** [February 9, 2026, 4:11pm UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/7 "2026-02-09T16:11:11Z")

</div>

Few replies/comments

1. The formatting of “block-style” notation got a bit lost in the survey.  
Even though all of you might know it let me still provide examples of that, for lists (and also “block-style” might be not much known as a term)

```auto
tags:
  - install
  - configure

```

```auto
users:
  name: John
  location: ghent

```

1. @kks , indeed there is an answer of Daniel. But also roughly that assuming that vars/main.yml typically would contain (some) variables with underscores.  
The reference for `__` are roles of Jeff Geerling (I guess all of them) and indeed [Good Practices for Ansible - GPA](https://redhat-cop.github.io/automation-good-practices/#_roles_good_practices_for_ansible) , one of the Style Guides that I used  
The convention on using `r_` for register variables is used more seldomly…

2. @bvitnik indeed, thank you I have seen it! For me the poll over there was a bit of “semi-final” and I created those 2 options that got into final. And actually right now “ensure” is losing in the final 🧐

---

<div class="post-metadata">

**Author:** ![kks](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kks/32/10352_2.png) [@kks](https://forum.ansible.com/u/kks)\
**Post date:** [February 9, 2026, 5:02pm UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/8 "2026-02-09T17:02:56Z")

</div>

> [@dbrennand](#):
>
> internal variables (those that are not expected to be set by users)

To me it looks like this recommendation predates argument\_specs file. Because with argument specs there is no question what can be set by user.  
There are number of questionable recommendations in that document from my point of view.

---

<div class="post-metadata">

**Author:** ![chris](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/chris/32/293_2.png) [@chris](https://forum.ansible.com/u/chris)\
**Post date:** [February 16, 2026, 4:10pm UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/9 "2026-02-16T16:10:35Z")

</div>

> [@volenbovsky](#):
>
> “external” quotes

What exactly does _“external” quotes_ mean?

---

<div class="post-metadata">

**Author:** ![flowerysong](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/flowerysong/32/2305_2.png) [@flowerysong](https://forum.ansible.com/u/flowerysong)\
**Post date:** [February 16, 2026, 6:57pm UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/10 "2026-02-16T18:57:51Z")

</div>

> [@chris](#):
>
> What exactly does _“external” quotes_ mean?

Quotes that are part of the YAML syntax rather than an actual part of the value.

```yaml
    foo:
      a: "In this scalar the \"external quotes\" are 'double' quotes"
      b: 'In this scalar the "external quotes" are ''single'' quotes'
      c: This scalar has no "external" 'quotes'

```

The main difference is whether backslash escapes are interpreted.

---

<div class="post-metadata">

**Author:** ![chris](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/chris/32/293_2.png) [@chris](https://forum.ansible.com/u/chris)\
**Post date:** [February 16, 2026, 8:04pm UTC](https://forum.ansible.com/t/survey-on-various-ansible-style-questions-cfgmgmtcamp-follow-up/45302/11 "2026-02-16T20:04:19Z")

</div>

I see, thanks for explaining it, I don’t personally like either so I’ll abstain 🙂 .
