@@ -43,18 +43,17 @@ Note that the subpackages can split up into more subpackages if needed.
43
43
44
44
Module names come from the names of the .py files containing function
45
45
declarations. You will need to create a new python file for each functionality.
46
- The name of the file containing the function declaration(s) for providing the
47
- functionality will be essentially the same as the function’s name but instead
48
- of the basic form use –ing form if it makes sense.
46
+ Name the modules in a brief, descriptive manner.
49
47
50
- - Try to create modules in a way that each module contains only one
48
+ - For common cases, try to create modules in a way that each module contains only one
51
49
functionality. Split this functionality into two function
52
50
declarations: one for external use and one (the core functionality)
53
51
for internal use. See e.g. implementation of [ clipping
54
52
functionality] ( ./eis_toolkit/raster_processing/clipping.py ) for
55
- reference.
53
+ reference. In some cases it can make sense to include multiple tools in one module,
54
+ so the one/two functions per module is not absolute.
56
55
57
- 1 . Functions
56
+ 3 . Functions
58
57
59
58
Name each function according to what it is supposed to do. Try to
60
59
express the purpose as simplistic as possible. In principle, each
@@ -92,9 +91,8 @@ maintainability and to avoid bugs.
92
91
93
92
For creating docstrings, we rely on google convention (see section 3.8
94
93
in [ link] ( https://google.github.io/styleguide/pyguide.html ) for more
95
- detailed instructions). Let's try to minimize the amount of code
96
- comments. Well defined docstrings should do most of the job with clear
97
- code structure.
94
+ detailed instructions). Well defined docstrings should do most of the job with clear
95
+ code structure, but code comments can be used (sparingly) too.
98
96
99
97
## Naming policy
100
98
@@ -232,9 +230,7 @@ including the same package, which was added to `pyproject.toml`, in
232
230
` environment.yaml ` . Please note that this file is only used for GitHub
233
231
workflows, otherwise we utilize poetry for dependency handling.
234
232
235
- ## Recent changes
236
-
237
- Some changes have been made to the style guide:
233
+ ## Additional style instructions
238
234
239
235
- Use ` numbers.Number ` as the type when both floats and integers are
240
236
accepted by functions:
@@ -289,14 +285,18 @@ def my_function(parameter_1: float, parameter_2: bool, parameter_seq: Sequence):
289
285
Here are some things to remember while implementing a new tool:
290
286
291
287
- Create an issue ** before or when you start** developing a
292
- functionality
288
+ functionality. Otherwise other people might have no idea you are
289
+ developing a feature.
293
290
- Adhere to the style guide
294
291
- Look at existing implementations and copy the form
295
292
- Enable pre-commit and fix style/other issues according to the
296
293
error messages
297
294
- Remember to use typing hints
298
295
- Write tests for your functions
299
296
- Add a .md file for you functionality
297
+ - Either implment a command-line interface function in ` cli.py ` in
298
+ approriate section of the file or raise an issue about the need to
299
+ implement a CLI function for your tool
300
300
- If you think the tool you are developing could use a separate
301
301
general utility function, make an issue about this need before
302
302
starting to develop it on your own. Also check if a utility function
0 commit comments