-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add section on documentation #19
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -758,3 +758,55 @@ def test_some_longwinded_process(support_client, factory): | |||||
``` | ||||||
|
||||||
You get the idea. | ||||||
|
||||||
|
||||||
## Documentation | ||||||
|
||||||
### READMEs | ||||||
|
||||||
Each directory within the domain layer should be modular and intuitive to use. A README can | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
optionally be placed in the root module directory and should detail specifics such as: | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
- How is this module laid out? | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
- How might someone use it? | ||||||
- What are the use cases? | ||||||
- How to extend behaviour (e.g. adding a new flow handler) | ||||||
- Who to contact if you run into errors | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think we should be including names of particular developers in the code base. That kind of thing gets out of date. If we want to do something like that, it might make more sense to have it in a google doc. |
||||||
|
||||||
### Docstrings | ||||||
|
||||||
Important classes and modules which are intended to be used throughout the whole codebase | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Might be worth having some guidance about when to include a big docstring and when it's okay to have less. Personally I think it should be possible to look at every function in isolation and have a good understanding about its inputs, outputs and what it's trying to achieve - but that doesn't always mean it needs a docstring. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not convinced we need this section - I think the gist could be captured with an extra sentence in the existing section on docstrings and comments. Plus, do we really want to suggest such a verbose docstring template - seem OTT to me. Is there an example of a docstring like this already? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @seddonym I agree with you, a lot of small functions wouldn't need documenting, I can make that clearer. @codeinthehole Most of the sections are suggested, but it was more a way of having a defined layout. I tried to ask questions that could help peopler structure their code more cleanly. |
||||||
should be well documented. Docstrings are helpful and, if used, should be laid out like the | ||||||
following: | ||||||
|
||||||
``` | ||||||
""" | ||||||
*<Short summary>* (1 line) | ||||||
* Responsibility | ||||||
|
||||||
*<More Information>* (5-10 lines) | ||||||
* How does it interact with the project? | ||||||
* What depends on it? | ||||||
* What does it depend on? | ||||||
* When is it used (when does it need to change)? | ||||||
* Data structures? | ||||||
|
||||||
Params: | ||||||
param1 (<type>): Description of parameter1. | ||||||
param2 (<type>): Description of parameter2. | ||||||
|
||||||
Returns (func): | ||||||
Description of what this function returns | ||||||
|
||||||
Attributes (class): | ||||||
attr1 (<type>): Description of attribute1. | ||||||
attr2 (<type>): Description of attribute2. | ||||||
|
||||||
Methods (class): | ||||||
method1 (<type>): Description of method1. | ||||||
method2 (<type>): Description of method2. | ||||||
""" | ||||||
``` | ||||||
|
||||||
Writing documentation helps you think about the structure of the module and how it fits with | ||||||
the SOLID principles. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section probably belongs in the "General Python" section, next to the existing note on docstrings.