<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Variables on C2 Platform</title><link>https://next.c2platform.org/tags/variables/</link><description>Recent content in Variables on C2 Platform</description><generator>Hugo</generator><language>en</language><atom:link href="https://next.c2platform.org/tags/variables/index.xml" rel="self" type="application/rss+xml"/><item><title>Dot Notation vs Bracket Notation in Ansible and Jinja</title><link>https://next.c2platform.org/docs/guidelines/coding/dot-vs-bracket-notation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://next.c2platform.org/docs/guidelines/coding/dot-vs-bracket-notation/</guid><description>&lt;div class="alert alert-primary" role="alert">


 Prefer dot notation for fixed keys, for example &lt;code>item.servername&lt;/code>. Use bracket
notation only when dot notation is not suitable, for example with dynamic keys
such as &lt;code>item[var_name]&lt;/code>.

&lt;/div>

&lt;h2 id="problem">Problem&lt;/h2>
&lt;p>Both dot notation and bracket notation are valid in Ansible and Jinja
expressions. Without a clear rule, codebases drift into a mixture of styles such
as &lt;code>item.name&lt;/code>, &lt;code>item['groups']&lt;/code>, and &lt;code>item[var_name]&lt;/code>.&lt;/p>
&lt;p>This inconsistency makes code harder to scan and review. It also creates noise
in examples and documentation, because readers have to infer whether the change
in syntax is meaningful or merely stylistic.&lt;/p></description></item></channel></rss>