1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
# Coding Style Guide
The purpose of this document is twofold:
1) To ensure that anyone who might like to make my code better understands
why I write python the way I do
2) To ensure *I* adhere to my own style because I'm terribly inconsistent
Being terribly inconsistent, the guidelines are not set in stone and if
you have a good argument for doing things a particular, I don't really care.
*BUT* first and foremost, *code must comply with PEP8 first*. This is easy
to automate. I like [black](https://pypi.org/project/black/) since it's
easy to use but there' plenty of advanced linters out there.
I usually invoke it like this to turn off forcing double quotes and
force the line length to 72:
```bash
black -S -l 72 file.py
```
That aside, I have the following idiosyncracies:
## 1) *Strings* are *double-quoted*. *Keys* and *chars* are *single-quoted*.
This is really just because I like how C does it. And Cpython's C-based so
why not?
Like so:
```python
string = "This is a phrase"
word = "word"
cur_char = 'a'
newline = '\n' # note, two characters, but it's still ONE char out
# keys are single-quoted to avoid confusion
dictionary = { 'key' "1245dqw3w431", 'return': newline }
```
The only exception is for strings with quotes in them (anything to avoid
escapes, really)
```python
quoted_string = (
'"You miss 100% of the shots you don't take - Wayne Gretsky"'
' - Michael Scott'
)
```
That brings me to my next point.
## 2) Long strings belong in parentheses
As in:
```python
longboi = (
"This is a really long string usefull when making help menus. Be\n"
"sure to leave s space at the end of each line, or add a new line\n"
"when needed.\n\n"
"Try your best to keep formatting accurate like this."
)
```
## 3) Tabs are four spaces and spaces are *ALWAYS* preferred to tabs
Again, see PEP8.
## 4) Always add spaces between arithmetic, but never for brackets
It's a pain to read:
```python
1/(2*sqrt(pi))*exp(x**2)
```
Do this
```python
1 / (2 * sqrt(pi)) * exp(x ** 2)
```
The same goes for logic operators
```python
true & false ^ true
```
## 5) EVERYTHING should be snake_case
This is python. Unless there's a compatibility thing (like a library's
code was written that way, or it matches an API variable), snake_case
is preferred.
```python
user_input = int(input()) # variable
MAX_INPUT = 1000 # constant
def judge_input(_input, _max): # function
if _max > _input:
print("Too big!")
judge_input(user_input, MAX_INPUT
class Input_Judger: # a class
# etc etc
```
Example exception:
```python
# this doesn't actually work, but you get the idea
r = requests.get("www.debian.org")
pageSize = r.json()['pageSize'] # camel case ok
```
## 6) If it's over 100 lines, you probably need a new file (and a class)
This is more of a general coding thing, but I've encountered so many
1000 line monster out there, I need to reiterate it. I understand how
these things come to be, having made a few myself in the beginning. You
get an idea and want to see it through in full. Like *On the Road* it
comes out as a scroll Merlin himself would be proud of.
But coming back to the scroll in a week half-drunk and half-tired is not
a situation you want to be caught in. You can always import *any* python
code you write with a simple:
```python
import filename
```
As long as it's in the same directory.
|
