From 9272d1b1b63984fcf0cfab8c27cdc271b0fe29c5 Mon Sep 17 00:00:00 2001 From: mjfernez Date: Sun, 7 Nov 2021 15:37:34 -0500 Subject: Commit all local files for mjfer.net Excepting files in site-files.git --- templates/site/tutorials/python/py-style.html | 34 --------------------------- 1 file changed, 34 deletions(-) delete mode 100644 templates/site/tutorials/python/py-style.html (limited to 'templates/site/tutorials/python/py-style.html') diff --git a/templates/site/tutorials/python/py-style.html b/templates/site/tutorials/python/py-style.html deleted file mode 100644 index 62de1ba..0000000 --- a/templates/site/tutorials/python/py-style.html +++ /dev/null @@ -1,34 +0,0 @@ -

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: code string = "This is a phrase" word = "word" cur_char = 'a' newline = '\n' # note, two characters, but it's still ONE char in output # 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) code 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"
-
-    "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: code 1/(2*sqrt(pi))*exp(x**2) Do this code 1 / (2 * sqrt(pi)) * exp(x ** 2) The same goes for logic operators code 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 code # 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