YAML How many spaces per indent?

Question

Is there any difference if i use one space, two or four spaces per indent level in YAML?

Are there any specific rules for space numbers per Structure type??

For example 4 spaces for nesting maps , 1 space per list item etc??

I am writing a yaml configuration file for elastic beanstalk .ebextensions and i am having really hard time constructing this correctly. Although i have valid yaml in YAML Validator elastic beanstalk seems to understand a different structure.

Holinshed

Although the specs tell that even an indentation by just one space is okay, I wouldn't be too surprised if tools would expect at least 2 space indentation. – Eriha

Answer 1

There is no requirement in YAML to indent any concrete number of spaces. There is also no requirement to be consistent. So for example, this is valid YAML:

a:
 b:
     - c
     -  d
     - e
f:
    "ghi"

Some rules might be of interest:

• Flow content (i.e. everything that starts with { or [) can span multiple lines, but must be indented at least as many spaces as the surrounding current block level.
• Block list items can (but don't need to) have the same indentation as the surrounding block level because - is considered part of the indentation:

a:    # top-level key
- b   # value of that key, which is a list
- c
c:    # next top-level key
 d    # non-list value which must be more indented

If you're using a linter, that might require a defined number of spaces, but the YAML spec itself and conforming YAML implementations don't.

Contrary

Is it only my who has trouble defining whether a key is nested or not? Even the tiny example above requires me to look very closely to see if f is on a level or b level. I really dislike this syntax. – Cott

@Cott Well nobody (I hope) uses one space for indentation, the example is merely academical. A proper code editor would give you indentation guide lines which is indeed necessary for larger files. If you dislike it, you can always use flow-style instead of indentation-based block style. – Contrary

Answer 2

The YAML spec for v 1.2 merely says that

In YAML block styles, structure is determined by indentation. In general, indentation is defined as a zero or more space characters at the start of a line.

To maintain portability, tab characters must not be used in indentation, since different systems treat tabs differently. Note that most modern editors may be configured so that pressing the tab key results in the insertion of an appropriate number of spaces.

The amount of indentation is a presentation detail and must not be used to convey content information.

So you can set the indent depth to your preference, as long as you use spaces and not tabs. Interestingly, IntelliJ uses 2 spaces by default.

Operon

"Different systems treat tabs differently", combined with the fact that "the amount of indentation is a presentation detail", is the exact reason for using tabs, exclusively, as indentation. The state of rational thought in development is absolutely dire. – Sofer

@Sofer In YAML, the line - - a can define the indentation of both the outer sequence (first -), the inner sequence (second -) and the scalar (a). Subsequent items of the inner sequence must be on the same level as the second - with only indentation preceding. You can't do this in a portable way with tabs, so the quoted text is indeed rational. – Contrary

@Contrary What you described is absolutely horrific; a nightmare which should never be made real – Sofer

Answer 3

Copied from https://docs.saltproject.io/en/3000/topics/troubleshooting/yaml_idiosyncrasies.html (https://archive.is/ZnwMb)

---

INDENTATION

The suggested syntax for YAML files is to use 2 spaces for indentation, but YAML will follow whatever indentation system that the individual file uses. Indentation of two spaces works very well for SLS files given the fact that the data is uniform and not deeply nested.

NESTED DICTIONARIES

When dictionaries are nested within other data structures (particularly lists), the indentation logic sometimes changes. Examples of where this might happen include context and default options from the file.managed state:

/etc/http/conf/http.conf:
  file:
    - managed
    - source: salt://apache/http.conf
    - user: root
    - group: root
    - mode: 644
    - template: jinja
    - context:
        custom_var: "override"
    - defaults:
        custom_var: "default value"
        other_var: 123

Notice that while the indentation is two spaces per level, for the values under the context and defaults options there is a four-space indent. If only two spaces are used to indent, then those keys will be considered part of the same dictionary that contains the context key, and so the data will not be loaded correctly. If using a double indent is not desirable, then a deeply-nested dict can be declared with curly braces:

/etc/http/conf/http.conf:
  file:
    - managed
    - source: salt://apache/http.conf
    - user: root
    - group: root
    - mode: 644
    - template: jinja
    - context: {
      custom_var: "override" }
    - defaults: {
      custom_var: "default value",
      other_var: 123 }

Mainsheet