Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions python.md
Original file line number Diff line number Diff line change
Expand Up @@ -758,3 +758,55 @@ def test_some_longwinded_process(support_client, factory):
```

You get the idea.


## Documentation

### READMEs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### READMEs
### Domain package READMEs

This section probably belongs in the "General Python" section, next to the existing note on docstrings.


Each directory within the domain layer should be modular and intuitive to use. A README can
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Each directory within the domain layer should be modular and intuitive to use. A README can
Each package within the domain layer should be well structured and intuitive to use. A README can

optionally be placed in the root module directory and should detail specifics such as:
Copy link
Contributor

Choose a reason for hiding this comment

The 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:
optionally be placed in the package directory and should detail specifics such as:


- How is this module laid out?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- How is this module laid out?
- How is this package laid out?

- 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link
Author

Choose a reason for hiding this comment

The 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.