From d0595724cd13a2274e34a813119cf457a796af75 Mon Sep 17 00:00:00 2001 From: mjfernez Date: Wed, 22 Dec 2021 16:40:46 -0500 Subject: Table of Contents! Adds some works in progress This commit adds a table of contents generated in the panupdate script. It also changes some links on the homepage to conform with removing '/site' as the parent directory --- thoughts/.description | 1 + thoughts/syntax/.description | 1 + thoughts/syntax/random-python-idiosyncrasies.html | 85 +++++++++++++++++++++++ 3 files changed, 87 insertions(+) create mode 100644 thoughts/.description create mode 100644 thoughts/syntax/.description create mode 100644 thoughts/syntax/random-python-idiosyncrasies.html (limited to 'thoughts') diff --git a/thoughts/.description b/thoughts/.description new file mode 100644 index 0000000..16f9528 --- /dev/null +++ b/thoughts/.description @@ -0,0 +1 @@ +Things I am less qualified to write about, but persist nonetheless. diff --git a/thoughts/syntax/.description b/thoughts/syntax/.description new file mode 100644 index 0000000..425358c --- /dev/null +++ b/thoughts/syntax/.description @@ -0,0 +1 @@ +Language on languages diff --git a/thoughts/syntax/random-python-idiosyncrasies.html b/thoughts/syntax/random-python-idiosyncrasies.html new file mode 100644 index 0000000..80e4563 --- /dev/null +++ b/thoughts/syntax/random-python-idiosyncrasies.html @@ -0,0 +1,85 @@ + + + + + + + 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 coala since it's friendly but there' plenty of advanced linters out there.

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 prefered 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

+ + -- cgit v1.2.3