Coding Style Guide
The purpose of this document is twofold:
- To ensure that anyone who might like to make my code better understands why I write python the way I do
- 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 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:
black -S -l 72 file.pyThat 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:
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)
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:
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:
1/(2*sqrt(pi))*exp(x**2)Do this
1 / (2 * sqrt(pi)) * exp(x ** 2)The same goes for logic operators
true & false ^ true5) 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.
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 etcExample exception:
# this doesn't actually work, but you get the idea
r = requests.get("www.debian.org")
pageSize = r.json()['pageSize'] # camel case ok6) 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:
import filenameAs long as it's in the same directory.