Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 5cb6344

Browse files
committed
streamlined coding guide and added naming conventions table
1 parent 309981d commit 5cb6344

File tree

7 files changed

+287
-206
lines changed

7 files changed

+287
-206
lines changed

doc/_static/mpl.css

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -161,3 +161,8 @@ div.wide-table table th.stub {
161161
font-style: italic;
162162
font-size: large;
163163
}
164+
165+
.checklist { list-style: none; padding: 0; margin: 0; }
166+
.checklist li { margin-left: 24px; padding-left: 23px; margin-right: 6px; }
167+
.checklist li:before { content: "\2610\2001"; margin-left: -24px; }
168+
.checklist li p {display: inline; }

doc/api/next_api_changes/README.rst

Lines changed: 9 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -22,11 +22,17 @@ author's initials. Typically, each change will get its own file, but you may
2222
also amend existing files when suitable. The overall goal is a comprehensible
2323
documentation of the changes.
2424

25-
Please avoid using references in section titles, as it causes links to be
26-
confusing in the table of contents. Instead, ensure that a reference is
27-
included in the descriptive text. A typical entry could look like this::
25+
A typical entry could look like this: ::
2826

2927
Locators
3028
~~~~~~~~
3129
The unused `Locator.autoscale()` method is deprecated (pass the axis
3230
limits to `Locator.view_limits()` instead).
31+
32+
Please avoid using references in section titles, as it causes links to be
33+
confusing in the table of contents. Instead, ensure that a reference is
34+
included in the descriptive text.
35+
36+
.. NOTE
37+
Lines 5-30 of this file are include in :ref:`api_whats_new`;
38+
therefore, please check the doc build after changing this file.

doc/devel/coding_guide.rst

Lines changed: 47 additions & 173 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,3 @@
1-
.. raw:: html
2-
3-
<style>
4-
.checklist { list-style: none; padding: 0; margin: 0; }
5-
.checklist li { margin-left: 24px; padding-left: 23px; margin-right: 6px; }
6-
.checklist li:before { content: "\2610\2001"; margin-left: -24px; }
7-
.checklist li p {display: inline; }
8-
</style>
9-
101
.. _pr-guidelines:
112

123
***********************
@@ -17,144 +8,82 @@ Pull request guidelines
178
<https://docs.github.com/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests>`__
189
are the mechanism for contributing to Matplotlib's code and documentation.
1910

20-
It is recommended to check that your contribution complies with the following
21-
rules before submitting a pull request:
22-
23-
* If your pull request addresses an issue, please use the title to describe the
24-
issue (e.g. "Add ability to plot timedeltas") and mention the issue number
25-
in the pull request description to ensure that a link is created to the
26-
original issue (e.g. "Closes #8869" or "Fixes #8869"). This will ensure the
27-
original issue mentioned is automatically closed when your PR is merged. See
28-
`the GitHub documentation
29-
<https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue>`__
30-
for more details.
31-
32-
* Formatting should follow the recommendations of PEP8_, as enforced by
33-
flake8_. Matplotlib modifies PEP8 to extend the maximum line length to 88
34-
characters. You can check flake8 compliance from the command line with ::
35-
36-
python -m pip install flake8
37-
flake8 /path/to/module.py
38-
39-
or your editor may provide integration with it. Note that Matplotlib
40-
intentionally does not use the black_ auto-formatter (1__), in particular due
41-
to its inability to understand the semantics of mathematical expressions
42-
(2__, 3__).
43-
44-
.. _PEP8: https://www.python.org/dev/peps/pep-0008/
45-
.. _flake8: https://flake8.pycqa.org/
46-
.. _black: https://black.readthedocs.io/
47-
.. __: https://github.com/matplotlib/matplotlib/issues/18796
48-
.. __: https://github.com/psf/black/issues/148
49-
.. __: https://github.com/psf/black/issues/1984
50-
51-
* All public methods should have informative docstrings with sample usage when
52-
appropriate. Use the :ref:`docstring standards <writing-docstrings>`.
53-
54-
* For high-level plotting functions, consider adding a simple example either in
55-
the ``Example`` section of the docstring or the
56-
:ref:`examples gallery <gallery>`.
57-
58-
* Changes (both new features and bugfixes) should have good test coverage. See
59-
:ref:`testing` for more details.
11+
We value contributions from people with all levels of experience. In particular,
12+
if this is your first PR not everything has to be perfect. We'll guide you
13+
through the PR process. Nevertheless, please try to follow our guidelines as well
14+
as you can to help make the PR process quick and smooth. If your pull request is
15+
incomplete or a work-in-progress, please mark it as a `draft pull requests <https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests>`_
16+
on GitHub and specify what feedback from the developers would be helpful.
6017

61-
* Import the following modules using the standard scipy conventions::
18+
Please be patient with reviewers. We try our best to respond quickly, but we have
19+
limited bandwidth. If there is no feedback within a couple of days, please ping
20+
us by posting a comment to your PR.
6221

63-
import numpy as np
64-
import numpy.ma as ma
65-
import matplotlib as mpl
66-
import matplotlib.pyplot as plt
67-
import matplotlib.cbook as cbook
68-
import matplotlib.patches as mpatches
6922

70-
In general, Matplotlib modules should **not** import `.rcParams` using ``from
71-
matplotlib import rcParams``, but rather access it as ``mpl.rcParams``. This
72-
is because some modules are imported very early, before the `.rcParams`
73-
singleton is constructed.
23+
Summary for pull request authors
24+
================================
7425

75-
* If your change is a major new feature, add an entry to the ``What's new``
76-
section by adding a new file in ``doc/users/next_whats_new`` (see
77-
:file:`doc/users/next_whats_new/README.rst` for more information).
26+
We recommend that you check that your contribution complies with the following
27+
guidelines before submitting a pull request:
7828

79-
* If you change the API in a backward-incompatible way, please document it in
80-
:file:`doc/api/next_api_changes/behavior`, by adding a new file with the
81-
naming convention ``99999-ABC.rst`` where the pull request number is followed
82-
by the contributor's initials. (see :file:`doc/api/api_changes.rst` for more
83-
information)
29+
.. rst-class:: checklist
8430

85-
* If you add new public API or change public API, update or add the
86-
corresponding type hints. Most often this is found in the corresponding
87-
``.pyi`` file for the ``.py`` file which was edited. Changes in ``pyplot.py``
88-
are type hinted inline.
31+
* Changes, both new features and bugfixes, should have good test coverage. See
32+
:ref:`testing` for more details.
8933

90-
* See below for additional points about :ref:`keyword-argument-processing`, if
91-
applicable for your pull request.
34+
* Update the :ref:`documentation <pr-documentation>` if necessary.
9235

93-
.. note::
36+
* All public methods should have informative docstrings with sample usage when
37+
appropriate. Use the :ref:`docstring standards <writing-docstrings>`.
9438

95-
The current state of the Matplotlib code base is not compliant with all
96-
of these guidelines, but we expect that enforcing these constraints on all
97-
new contributions will move the overall code base quality in the right
98-
direction.
39+
* For high-level plotting functions, consider adding a small example to the
40+
:ref:`examples gallery <gallery>`.
9941

42+
* If you add a major new feature or change the API in a backward-incompatible
43+
way, please document it as described in :ref:`new-changed-api`
10044

101-
.. seealso::
45+
* Code should follow our conventions as documented in our :ref:`coding_guidelines`
10246

103-
* :ref:`coding_guidelines`
104-
* :ref:`testing`
105-
* :ref:`documenting-matplotlib`
47+
* When adding or changing public function signatures, add :ref:`type hints <type-hints>`
10648

49+
* When adding keyword arguments, see our guide to :ref:`keyword-argument-processing`.
10750

51+
When opening a pull request on Github, please ensure that:
10852

109-
Summary for pull request authors
110-
================================
111-
112-
.. note::
53+
.. rst-class:: checklist
11354

114-
* We value contributions from people with all levels of experience. In
115-
particular if this is your first PR not everything has to be perfect.
116-
We'll guide you through the PR process.
117-
* Nevertheless, please try to follow the guidelines below as well as you can to
118-
help make the PR process quick and smooth.
119-
* Be patient with reviewers. We try our best to respond quickly, but we
120-
have limited bandwidth. If there is no feedback within a couple of days,
121-
please ping us by posting a comment to your PR.
55+
* Changes were made on a :ref:`feature branch <make-feature-branch>`.
12256

123-
When making a PR, pay attention to:
57+
* :ref:`pre-commit <pre-commit-hooks>` checks for spelling, formatting, etc pass
12458

125-
.. rst-class:: checklist
59+
* The pull request targets the :ref:`main branch <pr-branch-selection>`
12660

127-
* :ref:`Target the main branch <pr-branch-selection>`.
128-
* Adhere to the :ref:`coding_guidelines`.
129-
* Update the :ref:`documentation <pr-documentation>` if necessary.
130-
* Aim at making the PR as "ready-to-go" as you can. This helps to speed up
131-
the review process.
132-
* It is ok to open incomplete or work-in-progress PRs if you need help or
133-
feedback from the developers. You may mark these as
134-
`draft pull requests <https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests>`_
135-
on GitHub.
136-
* When updating your PR, instead of adding new commits to fix something, please
137-
consider amending your initial commit(s) to keep the history clean.
138-
You can achieve this by using
61+
* If your pull request addresses an issue, please use the title to describe the
62+
issue (e.g. "Add ability to plot timedeltas") and mention the issue number
63+
in the pull request description to ensure that a link is created to the
64+
original issue (e.g. "Closes #8869" or "Fixes #8869"). This will ensure the
65+
original issue mentioned is automatically closed when your PR is merged. For more
66+
details, see `linking an issue and pull request <https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue>`__.
13967

140-
.. code-block:: bash
68+
* :ref:`pr-automated-tests` pass
14169

142-
git commit --amend --no-edit
143-
git push [your-remote-repo] [your-branch] --force-with-lease
70+
For guidance on creating and managing a pull request, please see our
71+
:ref:`contributing <contributing>` and :ref:`pull request workflow <edit-flow>`
72+
guides.
14473

145-
See also :ref:`contributing` for how to make a PR.
14674

14775
Summary for pull request reviewers
14876
==================================
14977

15078
.. redirect-from:: /devel/maintainer_workflow
15179

152-
.. note::
80+
**Please help review and merge PRs!**
81+
82+
If you have commit rights, then you are trusted to use them. Please be patient
83+
and `kind <https://youtu.be/tzFWz5fiVKU?t=49m30s>`__ with contributors.
15384

154-
* If you have commit rights, then you are trusted to use them.
155-
**Please help review and merge PRs!**
156-
* Be patient and `kind <https://youtu.be/tzFWz5fiVKU?t=49m30s>`__ with
157-
contributors.
85+
When reviewing, please ensure that the pull request satisfies the following
86+
requirements before merging it:
15887

15988
Content topics:
16089

@@ -205,61 +134,6 @@ Documentation
205134

206135
* See :ref:`documenting-matplotlib` for our documentation style guide.
207136

208-
.. _release_notes:
209-
210-
New features and API changes
211-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
212-
When adding a major new feature or changing the API in a backward incompatible
213-
way, please document it by including a versioning directive in the docstring
214-
and adding an entry to the folder for either the what's new or API change notes.
215-
216-
+-------------------+-----------------------------+----------------------------------+
217-
| for this addition | include this directive | create entry in this folder |
218-
+===================+=============================+==================================+
219-
| new feature | ``.. versionadded:: 3.N`` | :file:`doc/users/next_whats_new/`|
220-
+-------------------+-----------------------------+----------------------------------+
221-
| API change | ``.. versionchanged:: 3.N`` | :file:`doc/api/next_api_changes/`|
222-
| | | |
223-
| | | probably in ``behavior/`` |
224-
+-------------------+-----------------------------+----------------------------------+
225-
226-
The directives should be placed at the end of a description block. For example::
227-
228-
class Foo:
229-
"""
230-
This is the summary.
231-
232-
Followed by a longer description block.
233-
234-
Consisting of multiple lines and paragraphs.
235-
236-
.. versionadded:: 3.5
237-
238-
Parameters
239-
----------
240-
a : int
241-
The first parameter.
242-
b: bool, default: False
243-
This was added later.
244-
245-
.. versionadded:: 3.6
246-
"""
247-
248-
def set_b(b):
249-
"""
250-
Set b.
251-
252-
.. versionadded:: 3.6
253-
254-
Parameters
255-
----------
256-
b: bool
257-
258-
For classes and functions, the directive should be placed before the
259-
*Parameters* section. For parameters, the directive should be placed at the
260-
end of the parameter description. The patch release version is omitted and
261-
the directive should not be added to entire modules.
262-
263137
.. _pr-labels:
264138

265139
Labels

0 commit comments

Comments
 (0)