You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: basics/docstrings.md
+30-21Lines changed: 30 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -121,28 +121,34 @@ It's recommended to always use `"""strings like this"""` for docstrings,
121
121
even if the docstring is only one line long. This way it's easy to add
122
122
more stuff to it later.
123
123
124
-
## Popular Docstrings Format
124
+
## Popular Docstring Formats
125
125
126
-
There might be different documentation strings available. You need not need to worry about the fact that you have to reinvent the wheel to study all. The formats of all the Documentation strings are nearly similar. The patterns are similar, but there are only nitty-gritty changes in each format.
126
+
There are different styles for writing docstrings. If you are contributing to
127
+
another Python project, make sure to use the same style as rest of that project
128
+
is using.
127
129
128
-
##### 1) Sphinx Style :
130
+
If you are starting a new project, then you can use whichever style you
131
+
want, but don't "reinventing the wheel"; use an existing style instead instead of
132
+
making up your own. Here are some examples of popular docstring styles to choose
133
+
from:
129
134
130
-
Sphinx is the easy and traditional style, verbose and was initially created specifically for the Python Documentation. Sphinx uses a reStructuredText which is similar in usage to Markdown.
135
+
### Sphinx Style
136
+
137
+
[Sphinx](https://www.sphinx-doc.org/en/master/) is the Python documentation tool
138
+
that [the official Python documentation](https://docs.python.org/3/) uses.
139
+
By default, sphinx expects you to write docstrings like this:
131
140
132
141
```python
133
142
classVehicle(object):
134
143
'''
135
-
The Vehicle object contains lots of vehicles
144
+
The Vehicle object contains lots of vehicles.
136
145
:param arg: The arg is used for ...
137
146
:type arg: str
138
-
:param `*args`: The variable arguments are used for ...
139
-
:param `**kwargs`: The keyword arguments are used for ...
140
147
:ivar arg: This is where we store arg
141
148
:vartype arg: str
142
149
'''
143
150
144
-
145
-
def__init__(self, arg, *args, **kwargs):
151
+
def__init__(self, arg):
146
152
self.arg = arg
147
153
148
154
defcars(self, distance, destination):
@@ -156,12 +162,14 @@ class Vehicle(object):
156
162
:returns: A Car mileage
157
163
:rtype: Cars
158
164
'''
159
-
pass
160
-
165
+
...
161
166
```
162
167
163
-
##### 2) Google Style :
164
-
Google Style is easier and more intuitive to use. It can be used for the shorter form of documentation. A configuration of python file needs to be done to get started, so you need to add either sphinx.ext.napoleon or sphinxcontrib.napoleon to the extensions list in conf.py.
168
+
### Google Style
169
+
170
+
Google Style is meant to be easier to read and use without a tool like sphinx.
'''We can't travel distance in vehicles without fuels, so here is the fuels
185
191
186
192
Args:
@@ -193,13 +199,16 @@ class Vehicles(object):
193
199
Returns:
194
200
cars: A car mileage
195
201
'''
196
-
pass
202
+
...
197
203
198
204
```
199
205
200
-
##### 3) Numpy Style :
206
+
###Numpy Style
201
207
202
-
Numpy style has a lot of details in the documentation. It is more verbose than other documentation, but it is an excellent choice if you want to do detailed documentation, i.e., extensive documentation of all the functions and parameters.
208
+
[Numpy](https://numpy.org/) is a large and popular Python library,
209
+
and numpy developers have their own docstring style.
210
+
It is an excellent choice if you want to do detailed documentation,
211
+
i.e., extensive documentation of all the functions and parameters.
0 commit comments