Checklist for submitting formal review

[kuziekj]

Here is a checklist of things to complete before submitting a formal review. An abridged version from info on this site:

https://mne.tools/stable/install/contributing.html#mne-python-coding-conventions

• Test coverage for new functionality (test output of boxy.py and compare to another source, such as p_pod)

• Document new functionality (thorough docstring explanations and tutorials explaining functionality)

• Avoid public API changes if possible (don't think we've made any such changes... Just added our own functions)

• Add deprecation warnings if removing/changing functionality (again, don't think this applies to us)

• Describes changes in the changelog, "doc/whats_new.rst" (sounds like this should be done AFTER the PR is finalised)

• Test locally before opening PR (kind of did both, tested locally and using CI tests)

• Make tests fast and thorough (currently tests compare raw, epoch, evoke to p_pod. Anything else? Need to make smaller data files for such tests)

• adhere to pep8 (currently seems fine, but can check by running "make flake")

• Use consistent variable names (should make sure variable names make sense too)

• follow NumPy style for docstrings (again, should be fine now but can be checked by running "make docstyle")

• Docstrings and documentation pages should cross-reference mentioned classes, functions, etc. (can probably use the "plot_70" tutorial as an example)

• Use single quotes where possible

• Prefer generators or comprehensives over filter() and map() (need to check into this...)

• Use explicit functional constructors (eg. list(), dict(), set())

• Avoid nested functions or class methods if possible

• Avoid *args and **kwargs in function/method signatures

• Import in this order (python built-in > standard scientific (eg. numpy, scipy) > others > MNE imports)

• Methods should modify in-place and return self

• Functions should return copies, where applicable

• Docstrings should contain informative names for return values, even if that particular name isn't used

• Visualisation capabilities should be available in method and function form

[kylemath]

thanks for getting this together, glad we have already done most, I think we are almost there

[kuziekj]

Yeah I think we're getting close. Helps that a lot of the checklist doesn't really apply to us since we're basing the code on what's already in mne.

[kuziekj]

I made a PR to address the list: #25