--- title: The standards file --- A standards file comprises a list of standards, and optionally some methods to check those standards. Create a file called standards.py (this can import other modules) {{< highlight Python "linenos=table" >}} from ansiblelater include Standard, Result tasks_are_uniquely_named = Standard(dict( # ID's are optional but if you use ID's they have to be unique id="ANSIBLE0003", # Short description of the standard goal name="Tasks and handlers must be uniquely named within a single file", check=check_unique_named_task, version="0.1", types=["playbook", "task", "handler"], )) standards = [ tasks_are_uniquely_named, role_must_contain_meta_main, ] {{< /highlight >}} When you add new standards, you should increment the version of your standards. Your playbooks and roles should declare what version of standards you are using, otherwise ansible-later assumes you're using the latest. The declaration is done by adding standards version as first line in the file. {{< highlight INI "linenos=table" >}} # Standards: 1.2 {{< /highlight >}} To add standards that are advisory, don't set the version. These will cause a message to be displayed but won't constitute a failure. When a standard version is higher than declared version, a message will be displayed 'WARN: Future standard' and won't constitute a failure. An example standards file is available at [ansiblelater/examples/standards.py](ansiblelater/examples/standards.py) If you only want to check one or two standards quickly (perhaps you want to review your entire code base for deprecated bare words), you can use the `-s` flag with the name of your standard. You can pass `-s` multiple times. {{< highlight Shell "linenos=table" >}} git ls-files | xargs ansible-later -s "bare words are deprecated for with_items" {{< /highlight >}} You can see the name of the standards being checked for each different file by running `ansible-later` with the `-v` option.