From f5f4faf06658c64622a992a9dd078fb378fdf077 Mon Sep 17 00:00:00 2001 From: William Zeng <44910023+wwzeng1@users.noreply.github.com> Date: Mon, 16 Oct 2023 11:16:49 -0700 Subject: [PATCH 1/2] Update sweep.yaml --- sweep.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sweep.yaml b/sweep.yaml index e22287a50f..8d99cb2d85 100644 --- a/sweep.yaml +++ b/sweep.yaml @@ -22,7 +22,7 @@ sandbox: - pre-commit run --files {file_path} rules: - - "There should not be large chunks of code that are just commented out. Docstrings and explanations in code are okay though." + - "Comments should be instructive, such as inline and docstring comments. Remove any code that has been commented out." - "Any clearly inefficient or redundant code can be optimized or refactored. Any improvements should not change the functionality of the code." - "All public classes and functions should have a numpydoc style docstring. This should include a description of the class or function, the parameters, the class attributes or function return values, and a usage example for the class or function." - "Update the relevant API page in 'docs/api_reference/' when new public functions and classes are added and not included in the API documentation. For example, if a new function is added to 'aeon/distances/', a `sphinx.ext.autosummary link` should also be added to 'docs/api_reference/distances.rst'. New sections in the page should not be created for individual functions and classes, add it to the most relevant existing one. Only add functions and classes which are not already in the relevant API page and avoid duplicate entries." From 2813e515db548cf02f85e0e78105ac70e060e738 Mon Sep 17 00:00:00 2001 From: Matthew Middlehurst Date: Mon, 16 Oct 2023 20:09:44 +0100 Subject: [PATCH 2/2] Update sweep.yaml --- sweep.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/sweep.yaml b/sweep.yaml index 8d99cb2d85..f85051a0e1 100644 --- a/sweep.yaml +++ b/sweep.yaml @@ -26,4 +26,3 @@ rules: - "Any clearly inefficient or redundant code can be optimized or refactored. Any improvements should not change the functionality of the code." - "All public classes and functions should have a numpydoc style docstring. This should include a description of the class or function, the parameters, the class attributes or function return values, and a usage example for the class or function." - "Update the relevant API page in 'docs/api_reference/' when new public functions and classes are added and not included in the API documentation. For example, if a new function is added to 'aeon/distances/', a `sphinx.ext.autosummary link` should also be added to 'docs/api_reference/distances.rst'. New sections in the page should not be created for individual functions and classes, add it to the most relevant existing one. Only add functions and classes which are not already in the relevant API page and avoid duplicate entries." - - "We use unit tests for our code. If we have 'class.py', there can be a 'tests/test_class.py' relative to the directory of the file. It is not necessary to create a test file for each new class and function, but any file specific tests should be in similarly named file."