Contributing to rapidtide
This document explains how to set up a development environment for contributing to rapidtide and code style conventions we follow within the project. For a more general guide to rapidtide development, please see our contributing guide. Please also remember to follow our code of conduct.
Style Guide
Code
Docstrings should follow numpydoc convention. We encourage extensive documentation.
The code itself should follow PEP8 convention as much as possible, with at most about 500 lines of code (not including docstrings) per file*.
* obviously some of the existing files don’t conform to this - working on it…
Pull Requests
We encourage the use of standardized tags for categorizing pull requests. When opening a pull request, please use one of the following prefixes:
[ENH] for enhancements
[FIX] for bug fixes
[TST] for new or updated tests
[DOC] for new or updated documentation
[STY] for stylistic changes
[REF] for refactoring existing code
Pull requests should be submitted early and often! If your pull request is not yet ready to be merged, please also include the [WIP] prefix. This tells the development team that your pull request is a “work-in-progress”, and that you plan to continue working on it.
A note on current coding quality and style
This code has been in active development since June of 2012. This has two implications. The first is that it has been tuned and refined quite a bit over the years, with a lot of optimizations and bug fixes - most of the core routines have been tested fairly extensively to get rid of the stupidest bugs. I find new bugs all the time, but most of the showstoppers seem to be gone. The second result is that the coding style is all over the place. When I started writing this, I had just moved over from C, and it was basically a mental port of how I would write it in C (and I do mean just “C”. Not C++, C#, or anything like that. You can literally say my old code has no Class (heh heh)), and was extremely unpythonic (I’ve been told by a somewhat reliable source that looking over some of my early python efforts “made his eyes bleed”). Over the years, as I’ve gone back and added functions, I periodically get embarrassed and upgrade things to a somewhat more modern coding style. I even put in some classes - that’s what the cool kids do, right? But the pace of that effort has to be balanced with the fact that when I make major architectural changes, I tend to break things. So be patient with me, and keep in mind that you get what you pay for, and this cost you nothing! Function before form.