anchor.diff:  | Parameters to Ansible modules SHOULD use the Yaml dictionary format when 3 or more parameters are being passed
   |===
   
  -When a module has several parameters that are being passed in, it's hard to see exactly what value each parameter is getting. It is preferred to use the Ansible Yaml syntax to pass in parameters so that it's more clear what values are being passed for each paramemter.
  +When a module has several parameters that are being passed in, it's hard to see exactly what value each parameter is getting. It is preferred to use the Ansible Yaml syntax to pass in parameters so that it's more clear what values are being passed for each parameter.
   
   .Bad:
   [source,yaml]
  
positive.code: [[Ansible-Roles-SHOULD-be-named-like-technology_component_subcomponent]]
  [cols="2v,v"]
  |===
  | [[Ansible-Roles-SHOULD-be-named-like-technology_component_subcomponent, Rule]]
  | Ansible Roles SHOULD be named like technology_component[_subcomponent].
  |===
  
  
negative.code: === Method Signatures
  
  '''
  [[When-adding-a-new-parameter-to-an-existing-method-a-default-value-SHOULD-be-used]]
  [cols="2v,v"]
  |===
  | <<When-adding-a-new-parameter-to-an-existing-method-a-default-value-SHOULD-be-used, Rule>>
  | When adding a new parameter to an existing method, a default value SHOULD be used
  |===
  The purpose of this rule is to make it so that method signatures are backwards compatible.
  
  