Skip to content

Commit a0b32a9

Browse files
committed
Remove misc python programming recommendations
We want to keep the style guide as minimal as possible. A separate miscellaneous programming recommendations document might be added in the future.
1 parent e8f1e72 commit a0b32a9

File tree

1 file changed

+0
-41
lines changed

1 file changed

+0
-41
lines changed

python.md

Lines changed: 0 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -167,44 +167,3 @@ Use `f"...{var}"` when writing Python 3.6+ code, or `"...{0}".format(var)`
167167
anywhere. `"..." + var` may be used for simple cases, but beware of pitfalls
168168
such as easily missed whitespace, or `var` not being a string. Don't use the
169169
old `"...%s" % var`-notation.
170-
171-
172-
## Programming Recommendations
173-
174-
### Miscellaneous
175-
176-
<!-- TODO: This recommendation is an updated remainder of the old style guide.
177-
It seems a bit lost here. -->
178-
179-
- Avoid large vertical separation of `if` and `else` keywords.
180-
```python
181-
# NO:
182-
if bizbaz:
183-
frobnicate(flimflam)
184-
...
185-
...
186-
...
187-
188-
else:
189-
raise YamException("No bizbaz, no frobnicate!")
190-
```
191-
Use the *"return early"* pattern, if the `else` clause would raise an
192-
exception or returns:
193-
194-
```python
195-
# YES:
196-
if not bizbaz:
197-
raise YamException("No bizbaz, no frobnicate!")
198-
199-
frobnicate(flimflam)
200-
...
201-
...
202-
...
203-
204-
```
205-
Returning early is generally useful to avoid excessive levels of nesting
206-
(aka. *"arrowhead anti-pattern"*).
207-
208-
If returning early is not an option, and `if` and `else` are thus both
209-
needed, it is slightly preferable to keep the shorter clause first, so that
210-
the `else` isn't too far from the `if`.

0 commit comments

Comments
 (0)