feat: shorten some excessively long names (#787)

Closes #772

### Summary of Changes

* Attributes or parameters that describe a count/number of something now
have the suffix `_count` instead of the prefix `number_of`.
* Abbreviate `maximum` to `max` and `minimum` to `min`.
* Update project guidelines.

---------

Co-authored-by: megalinter-bot <[email protected]>

benchmarks/metrics/classification.py

@@ -3,11 +3,11 @@
 from timeit import timeit
 
 import polars as pl
-
-from benchmarks.table.utils import create_synthetic_table
 from safeds.data.tabular.containers import Table
 from safeds.ml.metrics import ClassificationMetrics
 
+from benchmarks.table.utils import create_synthetic_table
+
 REPETITIONS = 10
 
 
@@ -62,6 +62,6 @@ def _run_recall() -> None:
                 {
                     "method": list(timings.keys()),
                     "timing": list(timings.values()),
-                }
-            )
+                },
+            ),
         )

benchmarks/table/column_operations.py

@@ -45,6 +45,6 @@ def _run_summarize_statistics() -> None:
             {
                 "method": list(timings.keys()),
                 "timing": list(timings.values()),
-            }
-        )
+            },
+        ),
     )

benchmarks/table/row_operations.py

@@ -1,7 +1,6 @@
 from timeit import timeit
 
 import polars as pl
-
 from safeds.data.tabular.containers import Table
 
 from benchmarks.table.utils import create_synthetic_table
@@ -34,7 +33,7 @@ def _run_shuffle_rows() -> None:
 
 
 def _run_slice_rows() -> None:
-    table.slice_rows(length=table.number_of_rows // 2)._lazy_frame.collect()
+    table.slice_rows(length=table.row_count // 2)._lazy_frame.collect()
 
 
 def _run_sort_rows() -> None:
@@ -116,6 +115,6 @@ def _run_transform_column() -> None:
                 {
                     "method": list(timings.keys()),
                     "timing": list(timings.values()),
-                }
-            )
+                },
+            ),
         )

benchmarks/table/utils/create_synthetic_table.py

@@ -4,8 +4,8 @@
 
 
 def create_synthetic_table(
-    number_of_rows: int,
-    number_of_columns: int,
+    row_count: int,
+    column_count: int,
     *,
     min_value: int = 0,
     max_value: int = 1000,
@@ -15,9 +15,9 @@ def create_synthetic_table(
 
     Parameters
     ----------
-    number_of_rows:
+    row_count:
         Number of rows in the Table.
-    number_of_columns:
+    column_count:
         Number of columns in the Table.
     min_value:
         Minimum value of the random data.
@@ -30,8 +30,5 @@ def create_synthetic_table(
         A Table with random numerical data.
     """
     return Table(
-        {
-            f"column_{i}": [randrange(min_value, max_value) for _ in range(number_of_rows)]
-            for i in range(number_of_columns)
-        }
+        {f"column_{i}": [randrange(min_value, max_value) for _ in range(row_count)] for i in range(column_count)},
     )

docs/development/guidelines/code_review.md

@@ -0,0 +1,64 @@
+# Code review
+
+This document describes general guidelines for developers when reviewing a pull request (PR).
+
+## Verify that the PR solves the addressed issue
+
+### Understand the issue
+
+* Read the issue that was addressed by the PR and make sure you understand it.
+* Read any discussions that occurred on the issue page.
+
+### Check the PR
+
+* Check the PR for __completeness__: Was every point from the issue covered?
+* Check for __correctness__: Were the problems described in the issue solved in the intended way?
+* (For PRs that introduce new features:) Check the design - does it comply with these guidelines?
+* Check for potential bugs - edge cases, exceptions that may be raised in functions that were called etc.
+* Check the code style: Is it readable? Do variables have sensible names? Is it consistent to existing code? Is there a
+  better / more elegant way to do certain things
+  (e.g. [f-string](https://docs.python.org/3/tutorial/inputoutput.html#tut-f-strings) instead of manual string
+  concatenation)?
+* Check any issues reported by linters.
+
+## Check the tests
+
+* Run the tests locally.
+* Check if there are any warnings that are not caught by the test suite.
+* Make sure the test cases are complete - do they cover all edge cases (e.g. empty tables)?
+* Make sure they comply to our [project guidelines][guidelines-tests] - are the tests parametrized and do all testcases
+  have descriptive IDs?
+
+## Verify that the PR does not break existing code
+
+This is largely covered by the automated tests. However, you should always:
+
+* Make sure all tests actually ran through (pytest, linter, code coverage).
+* Make sure that the branch is up-to-date with the `main` branch, so you actually test the behaviour that will result
+  once the feature branch is merged.
+
+## Check the PR format
+
+* Check that the PR title starts with a
+  fitting [type](https://github.com/Safe-DS/.github/blob/main/.github/CONTRIBUTING.md#types)
+  (e.g. `feat`, `fix`, `docs`, ...)
+* Check that the changes introduced by the PR are documented in the PR message.
+
+## Requesting changes
+
+If you found any issues with the reviewed PR, navigate to the `Files changed` tab in the PR page and click on the
+respective line to add your comments.
+
+For more details on specific review features, check out the [documentation on GitHub][github-review].
+
+## Finishing the review
+
+When done, finish your review by navigating to the `Files changed` tab and clicking the green `Review changes` button on
+the top right.
+
+If you found no issues, select the `Approve` option to approve the changes made by the PR. If you found any problems,
+select `Request Changes` instead.
+
+[guidelines-tests]: tests.md
+
+[github-review]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests

docs/development/guidelines/code_style.md

@@ -0,0 +1,32 @@
+# Code style
+
+## Consistency
+
+If there is more than one way to solve a particular task, check how it has been solved elsewhere in the codebase and
+stick to that solution.
+
+## Sort exported classes in `__init__.py`
+
+Classes defined in a module that other classes shall be able to import must be defined in a list named `__all__` in the
+module's `__init__.py` file. This list should be sorted in the same order that the declarations are imported in the
+file. This reduces the likelihood of merge conflicts when adding new classes to it.
+
+!!! success "**DO** (library code):"
+
+    ```py
+    __all__ = [
+        "Column",
+        "Row",
+        "Table",
+    ]
+    ```
+
+!!! failure "**DON'T** (library code):"
+
+    ```py
+    __all__ = [
+        "Table",
+        "Column",
+        "Row",
+    ]
+    ```