8000 WIP: document our guidelines/coding conventions by sciunto · Pull Request #2616 · scikit-image/scikit-image · GitHub
[go: up one dir, main page]

Skip to content

WIP: document our guidelines/coding conventions #2616

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

sciunto
Copy link
Member
@sciunto sciunto commented Apr 14, 2017

Description

As discussed on the ML, in this PR, we will start to list our guidelines related to our API.

https://mail.python.org/archives/list/scikit-image@python.org/thread/QKGR7YSC34MMXWFWLZNHHL3HJCBSAXN3/

TODO

References

@sciunto sciunto added 💬 Discussion 📄 type: Documentation Updates, fixes and additions to documentation 💪 Work in progress labels Apr 14, 2017
GUIDELINES.txt Outdated
@@ -0,0 +1,7 @@
Guidelines
Copy link
Member

Choose a reason for hiding this comment

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

Guidelines & Coding Conventions, perhaps?

Copy link

Choose a reason for hiding this comment

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

Coding conventions would be great. Especially naming conventions.

@@ -0,0 +1,7 @@
Guidelines
==========

Copy link
Member

Choose a reason for hiding this comment

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

Now just to figure out what common pieces of advice we give contributors :)

@sciunto sciunto changed the title WIP: document our guidelines WIP: document our guidelines/coding conventions Apr 15, 2017

from skimage import data

img = data.coins()
Copy link
Member

Choose a reason for hiding this comment

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

This has to be image :)

Copy link
Member Author

Choose a reason for hiding this comment

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

@soupault Please, read my comment: #2538 (comment) and add your point of view :)

Copy link
Member

Choose a reason for hiding this comment

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

Works fine to me either way. :)

@sciunto sciunto added this to the 0.14 milestone May 5, 2017
@sciunto sciunto modified the milestones: 0.14, 0.15 Jan 22, 2018
@sciunto sciunto mentioned this pull request Jun 24, 2018
7 tasks
@jni
Copy link
Member
jni commented Jun 24, 2018

@sciunto I wouldn't consider this dead, just dormant, thanks for awakening it. =) As a first step, I would remove all the copied sections from NumPyDoc and just link to the official guide:

https://numpydoc.readthedocs.io/en/latest/format.html

Overall I think this is a great addition! But I think use image. =P

@sciunto
Copy link
Member Author
sciunto commented Oct 28, 2018

I abandon this PR, I'm not motivated to continue on this. If someone else wants to document that, I'll be glad.

@sciunto sciunto modified the milestones: 0.15, 1.0 Jan 19, 2019
Copy link
Member
@hmaarrfk hmaarrfk left a comment

Choose a reason for hiding this comment

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

I feel like most of this is or should be upstreamed. No need to duplicate it here.

Docstring
---------

documentation string (docstring) is a string that describes a module,
Copy link
Member

Choose a reason for hiding this comment

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

Capitalization. Leading space

output. Rather than sacrificing the readability of the docstrings, we
have written pre-processors to assist Sphinx_ in its task.

The length of docstring lines should be kept to 75 characters to
Copy link
Member

Choose a reason for hiding this comment

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

I think this should be removed. This has fallen out of favor in recent years... Let's move on from the 70s

If it is not necessary to specify a keyword argument, use
``optional``::

x : int, optional
Copy link
Member

Choose a reason for hiding this comment

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

I know you all have been adding optional, but I feel like this is the expected default from a keyword argument that has been specified in the signature.

demonstrated function, must be explicit.


cumenting classes
Copy link
Member

Choose a reason for hiding this comment

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

Typo

@sciunto
Copy link
Member Author
sciunto commented Sep 12, 2019

If you want to continue this PR, feel free! :)

@hmaarrfk
Copy link
Member

Not particularly. I guess I didn't see the point that you abbandoned it too.

@jni
Copy link
Member
jni commented Sep 13, 2019

Totally into this PR, but there are quite a few changes I'd make. As @hmaarrfk, anything that can be upstreamed, should, by pointing to PEP257 and NumPy's docstring formatting guidelines. I don't have time to do it now but let's leave it open so the work is ready to be picked up by someone.

Base automatically changed from master to main February 18, 2021 18:22
@lagru lagru removed this from the 1.0 milestone Aug 18, 2022
@lagru
Copy link
Member
lagru commented Aug 18, 2022

I'm slowly going through the 1.0 milestone. Removing this from 1.0 as this is more a general documentation improvement and not specific to a release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants
0