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: STYLE.md
+52-6Lines changed: 52 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,11 @@
1
-
2
1
# Ops Python style guide
3
2
4
3
This is the Python style guide we use for the Ops project. However, it's also the style we're converging on for other projects maintained by the Charm Tech team.
5
4
6
5
We use Ruff for formatting, and run our code through the Pyright type checker. We also try to follow [PEP 8](https://peps.python.org/pep-0008/), the official Python style guide. However, PEP 8 is fairly low-level, so in addition we've come up with the following style guidelines.
7
6
7
+
New code should follow these guidelines, unless there's a good reason not to. Sometimes existing code doesn't follow these rules, but we're happy for it to be updated to do so (either all at once or as nearby code is changed).
8
+
8
9
Of course, this is just a start! We add to this list as things come up in code review and we make a team decision.
9
10
10
11
@@ -17,7 +18,7 @@ Of course, this is just a start! We add to this list as things come up in code r
17
18
18
19
## Simplicity
19
20
20
-
### Avoid nested comprehensions
21
+
### Avoid nested comprehensions and generators
21
22
22
23
"Flat is better than nested."
23
24
@@ -27,7 +28,7 @@ Of course, this is just a start! We add to this list as things come up in code r
27
28
units = [units for app in model.apps for unit in app.units]
28
29
29
30
for current in (
30
-
status for status in pebble.ServiceStatus if status isnot pebble.ServiceStatus.ACTIVE
31
+
status for status in pebble.ServiceStatus if status != pebble.ServiceStatus.ACTIVE
31
32
):
32
33
...
33
34
```
@@ -40,13 +41,51 @@ for app in model.apps:
40
41
for unit in app.units:
41
42
units.append(unit)
42
43
43
-
active_statuses = [status for status in pebble.ServiceStatus if status != pebble.ServiceStatus.ACTIVE]
44
-
for current in active_statuses:
44
+
for current in pebble.ServiceStatus:
45
+
if status == pebble.ServiceStatus.ACTIVE:
46
+
continue
45
47
...
46
48
```
47
49
48
50
## Specific decisions
49
51
52
+
### Import modules, not objects
53
+
54
+
"Namespaces are one honking great idea -- let's do more of those!"
55
+
56
+
When reading code, it's significantly easier to tell where a name came from if it is prefixed with the package name.
57
+
58
+
An exception is names from `typing` -- type annotations get too verbose if these all have to be prefixed with `typing.`.
This is six of one, half a dozen of the other, but we've decided that saying `if color == Color.RED` is nicer than `if color is Color.RED` as `==` is more typical for integer- and string-like values, and if you do use an `IntEnum` or `StrEnum` you should use `==` anyway.
@@ -76,6 +115,13 @@ if status != pebble.ServiceStatus.ACTIVE:
76
115
77
116
## Docs and docstrings
78
117
118
+
### Use British English
119
+
120
+
[Canonical's documentation style](https://docs.ubuntu.com/styleguide/en/) is to use British spellings, and we try to follow that here. For example, "colour" rather than "color", "labelled" rather than "labeled", "serialise" rather than "serialize", and so on.
121
+
122
+
It's a bit less clear when we're dealing with code and APIs, as those normally use US English, for example, `pytest.mark.parametrize`, and `color: #fff`.
123
+
124
+
79
125
### Spell out abbreviations
80
126
81
-
Prefer spelling out abbreviations and acronyms in docstrings, for example, "for example" rather than "e.g.", "that is" rather than "i.e.", and "unit testing" rather than UT.
127
+
Prefer spelling out abbreviations and acronyms in docstrings, for example, "for example" rather than "e.g.", "that is" rather than "i.e.", "and so on" rather than "etc", and "unit testing" rather than UT.
0 commit comments