nextstrain / augur

Pipeline components for real-time phylodynamic analysis
https://docs.nextstrain.org/projects/augur/
GNU Affero General Public License v3.0
268 stars 128 forks source link

Create a guide for contributing code to augur #242

Open huddlej opened 5 years ago

huddlej commented 5 years ago

To provide core developers and other contributors with a formal style guide, we could create some minimal documentation about how to contribute source code along the lines of pandas, matplotlib, etc.

At the start, this documentation could include our agreed style conventions like which docstring format to use, exceptions to PEP8, etc.

This documentation could live in CONTRIBUTING.md, initially.

tsibley commented 5 years ago

:+1:

rneher commented 5 years ago

good idea. But we first need to agree among us...

my vote is for numpy docstrings and a number of white space exceptions to PEP8 rules (I think white space in arithmetic expressions should reflect operator precedence, for example).

tsibley commented 5 years ago

I should clarify. I'm :+1: about expressing project preferences on readability, use of descriptive names, expectation of documentation, and other broad code-organization concerns, but :-1: about bikeshedding details like where not to put whitespace, when to use parentheses, how long lines should be, list comprehensions vs. function chains, etc. I think "generally consistent and readable" is more important than "must pass a linter."

jameshadfield commented 5 years ago

Seems like a good idea. I know we added a linter config to augur, but does anyone actually use it?

I'd favor an emphasis on documentation (markdown files in a docs directory), docstrings in the code and an overall description of what constitutes a module and what the interfaces should look like (if one can generalise).