* [PEP 8](https://www.python.org/dev/peps/pep-0008/) is a great Python style guide, which you should read.
* PEP 8 must not be strictly followed in all aspects, but most of it is good advice.
* The line is limited to 160 characters.
* To run checks for things we care about, use [ansible-test](https://docs.ansible.com/ansible/dev_guide/testing_pep8.html#running-locally).
* To run checks for things we care about, use [ansible-test](https://docs.ansible.com/ansible/devel/dev_guide/testing_sanity.html).
* Similarly, additional checks can be made with "make pyflakes".
* There is no need to submit code changes for PEP 8 and pyflakes fixes, as these break attribution history. Project leadership will make these periodically.
* Do not submit pull requests that simply adjust whitespace in the code.
@ -28,7 +28,7 @@ PEP 8 and basic style checks
Testing
=======
* Much of ansible's testing needs are in integration, not unit tests. Add module tests there.
* Much of Ansible's testing needs are in integration, not unit tests. Add module tests there.
* That being said, there are unit tests too!
* Code written must absolutely pass tests (i.e. "make tests")
* You should anticipate any error paths in your code and test down those error paths.
@ -65,7 +65,7 @@ For instance ensuring that a specific tenant exists, is done using the following
description: Customer XYZ
state: present
A complete list of existing ACI modules is available for the latest stable release on the :ref:`list of network modules <network_modules>`. You can also view the `current development version <http://docs.ansible.com/ansible/devel/modules/list_of_network_modules.html#aci>`_.
A complete list of existing ACI modules is available for the latest stable release on the :ref:`list of network modules <network_modules>`. You can also view the `current development version <https://docs.ansible.com/ansible/devel/modules/list_of_network_modules.html#aci>`_.