From f3c2a04094a3b3c49b27b9fa3871a1e125c5da5b Mon Sep 17 00:00:00 2001
From: nutan <nutan.chen@gmail.com>
Date: Mon, 15 Apr 2024 21:37:30 +0200
Subject: [PATCH] pre-commit doc

---
 .../contributing/development/code_quality.rst | 22 +++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/docs/contributing/development/code_quality.rst b/docs/contributing/development/code_quality.rst
index 71f8196315c..acd65445ca6 100644
--- a/docs/contributing/development/code_quality.rst
+++ b/docs/contributing/development/code_quality.rst
@@ -19,7 +19,7 @@ TARDIS follows the `PEP 8 <https://www.python.org/dev/peps/pep-0008/>`_ style gu
 Black
 -----
 `Black <https://black.readthedocs.io/en/stable/index.html>`_ is a PEP 8 compliant opinionated code formatter. At TARDIS. we use Black to automatically conform to PEP 8. It is already installed in the TARDIS conda environment, so all you have to do is to run Black before commiting your changes: ::
-    
+
     black {source_file_or_directory}
 
 A better method is to run Black automatically - first `integrate it within the code editor <https://black.readthedocs.io/en/stable/editor_integration.html>`_ you use and then enable the "format on save" or "format on type" option in your editor settings.
@@ -43,6 +43,20 @@ Currently, Ruff is not integrated with the TARDIS CI and is not a requirement fo
 
 .. note :: Ruff can also be used for formatting code, but for now we recommend using Black for this purpose as the CI is configured to run Black on all PRs.
 
+Pre-commit (Optional)
+----
+`Pre-commit <https://pre-commit.com/>`_ hooks are tools that help enforce quality standards by running checks on your code before you commit. If you choose to use pre-commit on your local machine, please follow these steps:
+
+Install pre-commit by running: ::
+
+    pip install pre-commit
+
+Set up the pre-commit hooks with: ::
+
+    pre-commit install
+
+This needs to be done only once per repository. The pre-commit hooks will now automatically run on each commit to ensure your changes meet our code quality standards.
+
 Naming Conventions
 ------------------
 
@@ -50,7 +64,7 @@ While Black automatically conforms your code to a majority of the PEP 8 style gu
 
 - Function names should be lowercase, with words separated by underscores as necessary to improve readability (i.e. snake_case).
 
-- Variable names follow the same convention as function names. 
+- Variable names follow the same convention as function names.
 
 - Class names should use the CapWords convention.
 
@@ -91,7 +105,7 @@ At TARDIS, we follow the `Numpy docstring format <https://numpydoc.readthedocs.i
 
 Some of the important formatting conventions to note here are:
 
-- The docstring should have no leading or trailing carriage returns, and there should be a carriage return between each segment. 
+- The docstring should have no leading or trailing carriage returns, and there should be a carriage return between each segment.
 
 - At the start of the docstring there is a summary explaining the purpose of the function/class/module/method. This summary should follow standard English syntax, starting with a capitalized letter and ending with appropriate punctuation.
 
@@ -102,7 +116,7 @@ Some of the important formatting conventions to note here are:
 - In the above example the return variable and type is specified. For the "Returns" section, the type must always be stated, even if the variable is not. The "Returns" section should follow the format of:
 
 .. code-block:: python
-    
+
     """
     Returns
     -------