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