You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+29Lines changed: 29 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -80,6 +80,32 @@ Now you will be automatically reminded to add docstrings to your code. `black` w
80
80
81
81
Run `git config blame.ignoreRevsFile .github/.git-blame-ignore-revs`
82
82
83
+
## Code style conventions:
84
+
85
+
Most of our codebase is written in Python.
86
+
87
+
### PEP compliance
88
+
89
+
We comply to the official PEP: E9, F63, F7, F82 code style and required every contribution to follow it. This is enforced by using [flake8](https://github.com/PyCQA/flake8) in our CI and in our [pre-commit hooks](https://github.com/jina-ai/docarray/blob/main/CONTRIBUTING.md#install-pre-commit-hooks).
90
+
91
+
### Python version
92
+
DocArray is compatible with Python 3.7 and above, therefore we can't accept contribution that used features from the newest Python versions without ensuring compatibility with python 3.7
93
+
94
+
### Code formatting
95
+
96
+
All of our Python codebase follows formatting standard. We are following the [PEP8](https://peps.python.org/pep-0008/) standard, and we require that every code contribution is formatted using [black](https://github.com/psf/black) with the default configurations.
97
+
If you have installed the [pre-commit hooks](https://github.com/jina-ai/docarray/blob/main/CONTRIBUTING.md#install-pre-commit-hooks) the formatting should be automatic on every commit. Moreover, our CI will block contributions that do not respect these conventions.
98
+
99
+
### Type Hint
100
+
101
+
Python is not a strongly typed programming language, nevertheless the use of [type hints](https://docs.python.org/3/library/typing.html)
102
+
contribute to a better codebase especially when reading, reviewing and refactoring. Therefore, we **highly** encourage every contribution
103
+
to fully utilise type hints. In some particular cases type hints can be cumbersome, therefore using type hints is not a hard requirement for contribution.
104
+
105
+
Contributions are expected to use type hints, especially in function signature, unless there is an arguably good reason not to do it.
106
+
107
+
Note: Example code in the documentation should also follow our code style conventions
108
+
83
109
84
110
<aname="-naming-conventions"></a>
85
111
## ☑️ Naming Conventions
@@ -227,6 +253,9 @@ Bonus: **Know when to break the rules**. Documentation writing is as much art as
227
253
2. Use the `{admonition}` boxes with care.
228
254
3. Use `{dropdown}` to hide optional content, such as long code snippets or console output.
229
255
256
+
257
+
Note: Example code in the documentation should also follow our code style conventions that you can find above
0 commit comments