Skip to content

Commit 36eaa19

Browse files
authored
Update CONTRIBUTING.md
1 parent 32e16b9 commit 36eaa19

File tree

1 file changed

+13
-13
lines changed

1 file changed

+13
-13
lines changed

CONTRIBUTING.md

+13-13
Original file line numberDiff line numberDiff line change
@@ -43,18 +43,17 @@ Note that the subpackages can split up into more subpackages if needed.
4343

4444
Module names come from the names of the .py files containing function
4545
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.
4947

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
5149
functionality. Split this functionality into two function
5250
declarations: one for external use and one (the core functionality)
5351
for internal use. See e.g. implementation of [clipping
5452
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.
5655

57-
1. Functions
56+
3. Functions
5857

5958
Name each function according to what it is supposed to do. Try to
6059
express the purpose as simplistic as possible. In principle, each
@@ -92,9 +91,8 @@ maintainability and to avoid bugs.
9291

9392
For creating docstrings, we rely on google convention (see section 3.8
9493
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.
9896

9997
## Naming policy
10098

@@ -232,9 +230,7 @@ including the same package, which was added to `pyproject.toml`, in
232230
`environment.yaml`. Please note that this file is only used for GitHub
233231
workflows, otherwise we utilize poetry for dependency handling.
234232

235-
## Recent changes
236-
237-
Some changes have been made to the style guide:
233+
## Additional style instructions
238234

239235
- Use `numbers.Number` as the type when both floats and integers are
240236
accepted by functions:
@@ -289,14 +285,18 @@ def my_function(parameter_1: float, parameter_2: bool, parameter_seq: Sequence):
289285
Here are some things to remember while implementing a new tool:
290286

291287
- 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.
293290
- Adhere to the style guide
294291
- Look at existing implementations and copy the form
295292
- Enable pre-commit and fix style/other issues according to the
296293
error messages
297294
- Remember to use typing hints
298295
- Write tests for your functions
299296
- 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
300300
- If you think the tool you are developing could use a separate
301301
general utility function, make an issue about this need before
302302
starting to develop it on your own. Also check if a utility function

0 commit comments

Comments
 (0)