-
Notifications
You must be signed in to change notification settings - Fork 18
better docstrings #144
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
better docstrings #144
Conversation
Hi Justus, thanks a lot, I really appreciate this! For the future I would suggest to gather these changes in fewer commits with meaningful commit messages (or squash them if that suits your workflow better). |
Hi Fabian, Just to clarify: I also haven't worked on help-functions in the modules and class-functions like .gamma_method() or .reweight() as they are not a priority for this in my opinion. (the first ones are only for internal use, the second ones just change the object they are called from) Of course I'd be happy to come up with something similar for these functions too if this is of interest. |
returns added for misc.py returns added for mpm.py reutrns added for fits.py
I guess this could be the first version of the docstrings. As mentioned above, there are still a lot of internal and class functions that have not been changed yet... Is this of interest? |
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.
Looks good to me, thanks! If you think additional documentation is useful for new users feel free to add it.
Inspired by the automatically generated docstrings from my last pull request and some questions that I got from someone working with the fit functions, I started adding Return statements in .addition to the usual parameter statements.
So far I have worked on the input methods. Of course, this is only a part of the full job.
I intend to add more of these in the future, if there is interest in having this. In my opinion this could be quite practical for people who are new to the code and who work with IDEs that show doctrings as hints (e.g. VS Code).
In fact I noticed, that there are already statements like these in the docstrings for some methods, however I thought having them in the same standardized format as the parameters could be good.
Of course I'd be more than happy for additional input on this matter. Especially in the cases in which I have not written the input methods, it could be good to have another pair of eyes looking at this.