mjfer.net

   

THOUGHTS/SYNTAX/RANDOM-PYTHON-IDIOSYNCRASIES

random-python-idiosyncrasies

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 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.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:

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 ^ 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.

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:

# 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:

import filename

As long as it's in the same directory.

Go up to parent folder (/thoughts/syntax)

CC0
To the extent possible under law, The author has waived all copyright and related or neighboring rights to content on mjfer.net. All work may be cited without attribution at the reader's discretion. However, if you do use the work here, or otherwise benefit from it, the author would love to hear about it! This work is published from: United States.