Rework formatting section of HACKING.rst

We now defer to ruff for all decisions on formatting. Additionally, we
have more (one more) custom hacking rules than the one currently
documented.

Change-Id: I351191cd853bbc2735ae875d08af2d39dc2f63a3
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

HACKING.rst

@@ -1,43 +1,31 @@
 openstacksdk Style Commandments
 ===============================
 
-Read the OpenStack Style Commandments
-https://docs.openstack.org/hacking/latest/
+- Step 1: Read the OpenStack Style Commandments
+  https://docs.openstack.org/hacking/latest/
+- Step 2: Read on
 
-Indentation
------------
+openstacksdk Specific Commandments
+----------------------------------
 
-PEP-8 allows for 'visual' indentation. **Do not use it**.
-Visual indentation looks like this:
+- [O300] ``setUpClass`` not allowed
 
-.. code-block:: python
+  ``setUpClass`` looks like it runs once for the class. In parallel test
+  execution environments though, it runs once per execution context. This makes
+  reasoning about when it is going to actually run and what is going to happen
+  extremely difficult and can produce hard to debug test issues.
 
-  return_value = self.some_method(arg1, arg1,
-                                  arg3, arg4)
+  Don't ever use it. It makes baby pandas cry.
 
-Visual indentation makes refactoring the code base unnecessarily hard.
+- [O310] Use of deprecated ``Exception`` class
 
-Instead of visual indentation, use this:
+Linting & Formatting
+--------------------
 
-.. code-block:: python
-
-  return_value = self.some_method(
-      arg1, arg1, arg3, arg4)
-
-That way, if some_method ever needs to be renamed, the only line that needs
-to be touched is the line with some_method.
-
-Additionally, if you need to line break at the top of a block, please indent
-the continuation line an additional 4 spaces, like this:
-
-.. code-block:: python
-
-  for val in self.some_method(
-          arg1, arg1, arg3, arg4):
-      self.do_something_awesome()
-
-Neither of these are 'mandated' by PEP-8. However, they are prevailing styles
-within this code base.
+We use `ruff <https://docs.astral.sh/ruff/>`__ in combination with `hacking
+<https://docs.openstack.org/hacking/latest/>`__ for linting and formatting.
+These can be executed using the ``pep8`` tox target (``tox -e pep8``) or by
+installing and running `pre-commit <https://pre-commit.com/>`__.
 
 Unit Tests
 ----------
@@ -45,12 +33,12 @@ Unit Tests
 Unit tests should be virtually instant. If a unit test takes more than 1 second
 to run, it is a bad unit test. Honestly, 1 second is too slow.
 
-All unit test classes should subclass `openstack.tests.unit.base.TestCase`. The
-base TestCase class takes care of properly creating `Connection` objects
-in a way that protects against local environment.
+All unit test classes should subclass ``openstack.tests.unit.base.TestCase``.
+The base ``TestCase`` class takes care of properly creating ``Connection``
+objects in a way that protects against local environment.
 
-Test cases should use requests-mock to mock out HTTP interactions rather than
-using mock to mock out object access.
+Test cases should use ``requests-mock`` to mock out HTTP interactions rather
+than using mock to mock out object access.
 
 Functional Tests
 -----------------
@@ -121,13 +109,3 @@ personas.
   def test_device_profile_admin(self):
       # get, list, and delete as admin
       ...
-
-Don't Use setUpClass
---------------------
-
-setUpClass looks like it runs once for the class. In parallel test execution
-environments though, it runs once per execution context. This makes reasoning
-about when it is going to actually run and what is going to happen extremely
-difficult and can produce hard to debug test issues.
-
-Don't ever use it. It makes baby pandas cry.