From 2841989fbcac0bb530133641127f0e73fb686114 Mon Sep 17 00:00:00 2001 From: mjfernez Date: Mon, 3 Jan 2022 17:41:42 -0500 Subject: Added neovim article. Syntax fixes in markdown --- thoughts/syntax/my-worst-habit.html | 53 ++++++++ thoughts/syntax/random-python-idiosyncrasies.html | 140 ++++++++++++++++------ 2 files changed, 157 insertions(+), 36 deletions(-) create mode 100644 thoughts/syntax/my-worst-habit.html (limited to 'thoughts') diff --git a/thoughts/syntax/my-worst-habit.html b/thoughts/syntax/my-worst-habit.html new file mode 100644 index 0000000..7d7698b --- /dev/null +++ b/thoughts/syntax/my-worst-habit.html @@ -0,0 +1,53 @@ + + + + + + + my-worst-habit + + + +

Overuse of parentheses, by far.

Why is this a bad thing? Parentheses, as read by most readers, tend to contain additional superfluous information when read. So naturally, the mind tends to pay less attention to what's inside (or at least my mind does). I also believe it represents some repressed psychological trauma, since a Professor once circled how many times I abused the double dash, "--", and I haven't quite felt comfortable using it since--unless it feels right.

The punctuation works in that last example, but relying on it leads to bad habits, and usually, sentences that droll on for far longer than welcome. Consider the following example from Naked Lunch:

Doc Browbeck was party inna second part. A retired abortionist and junk
+pusher (he was a veterinarian actually) recalled to service during the
+manpower shortage. Well, Doc had been in the hospital kitchen all
+morning goosing the nurses and tanking up on coal gas and Klim -- and
+just before the operation he sneaked a double shot of nutmeg to nerve
+himself up.
+
+(In England and especially in Edinburgh the citizens bubble coal gas
+through Klim -- a horrible form of powdered milk tasting like rancid
+chalk -- and pick up on the results. They hock everything to pay the
+gas bill, and when the man comes around to shut it off for the
+non-payment, you can hear their screams for miles. When a citizen is
+sick from needing it he says "I got the klinks" or "That old stove
+climbing up my back."
+
+Nutmeg. I quote from the author's article on narcotic drugs in the
+British Journal of Addiction (see Appendix): "Convicts and sailors
+sometimes have recourse to nutmeg. About a tablespoon is swallowed
+with water. Result vaguely similar to marijuana with side effects of
+headache and nausea. There are a number of narcotics of the nutmeg
+family in use among the Indians of South America. They are usually
+administered by sniffing a dried powder of the plant. The medicine
+men take these noxious substances and go into convulsive states. Their
+twitchings and mutterings are thought to have prophetic significance.")

This is the only example I know that dares to put parentheses and a long quote within parentheses, unless we're counting math textbooks. In a way it works, since if information is ever superfluous, the history of sailors getting high on nutmeg fits that bill. A careful reader might easily pick up on that, but to everyone else, I think a full paragraph of text in parentheses signals the reader to scroll down in the hopes that the story continues.

But just in case you think I'm just picking on William S. Burroughs, here's an example I regrettably wrote to a coworker recently with some details removed:

[...] As a precaution, I did review $NOBODY's recent
+$THING_I_WAS_ASKED_TO_REVIEW (if you would like a detailed report on
+that, I can pull that together for you).

Somehow, I managed to take the one point worth emphasizing (an entire sentence at that!) and de-emphasized it.

It's a habit I can't break. So please, if you are a caring reader, do complain when I overuse parentheses. I deserve it.

+ + diff --git a/thoughts/syntax/random-python-idiosyncrasies.html b/thoughts/syntax/random-python-idiosyncrasies.html index 80e4563..ba88071 100644 --- a/thoughts/syntax/random-python-idiosyncrasies.html +++ b/thoughts/syntax/random-python-idiosyncrasies.html @@ -12,6 +12,68 @@ div.column{display: inline-block; vertical-align: top; width: 50%;} div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;} ul.task-list{list-style: none;} + pre > code.sourceCode { white-space: pre; position: relative; } + pre > code.sourceCode > span { display: inline-block; line-height: 1.25; } + pre > code.sourceCode > span:empty { height: 1.2em; } + code.sourceCode > span { color: inherit; text-decoration: inherit; } + div.sourceCode { margin: 1em 0; } + pre.sourceCode { margin: 0; } + @media screen { + div.sourceCode { overflow: auto; } + } + @media print { + pre > code.sourceCode { white-space: pre-wrap; } + pre > code.sourceCode > span { text-indent: -5em; padding-left: 5em; } + } + pre.numberSource code + { counter-reset: source-line 0; } + pre.numberSource code > span + { position: relative; left: -4em; counter-increment: source-line; } + pre.numberSource code > span > a:first-child::before + { content: counter(source-line); + position: relative; left: -1em; text-align: right; vertical-align: baseline; + border: none; display: inline-block; + -webkit-touch-callout: none; -webkit-user-select: none; + -khtml-user-select: none; -moz-user-select: none; + -ms-user-select: none; user-select: none; + padding: 0 4px; width: 4em; + color: #aaaaaa; + } + pre.numberSource { margin-left: 3em; border-left: 1px solid #aaaaaa; padding-left: 4px; } + div.sourceCode + { } + @media screen { + pre > code.sourceCode > span > a:first-child::before { text-decoration: underline; } + } + code span.al { color: #ff0000; font-weight: bold; } /* Alert */ + code span.an { color: #60a0b0; font-weight: bold; font-style: italic; } /* Annotation */ + code span.at { color: #7d9029; } /* Attribute */ + code span.bn { color: #40a070; } /* BaseN */ + code span.bu { } /* BuiltIn */ + code span.cf { color: #007020; font-weight: bold; } /* ControlFlow */ + code span.ch { color: #4070a0; } /* Char */ + code span.cn { color: #880000; } /* Constant */ + code span.co { color: #60a0b0; font-style: italic; } /* Comment */ + code span.cv { color: #60a0b0; font-weight: bold; font-style: italic; } /* CommentVar */ + code span.do { color: #ba2121; font-style: italic; } /* Documentation */ + code span.dt { color: #902000; } /* DataType */ + code span.dv { color: #40a070; } /* DecVal */ + code span.er { color: #ff0000; font-weight: bold; } /* Error */ + code span.ex { } /* Extension */ + code span.fl { color: #40a070; } /* Float */ + code span.fu { color: #06287e; } /* Function */ + code span.im { } /* Import */ + code span.in { color: #60a0b0; font-weight: bold; font-style: italic; } /* Information */ + code span.kw { color: #007020; font-weight: bold; } /* Keyword */ + code span.op { color: #666666; } /* Operator */ + code span.ot { color: #007020; } /* Other */ + code span.pp { color: #bc7a00; } /* Preprocessor */ + code span.sc { color: #4070a0; } /* SpecialChar */ + code span.ss { color: #bb6688; } /* SpecialString */ + code span.st { color: #4070a0; } /* String */ + code span.va { color: #19177c; } /* Variable */ + code span.vs { color: #4070a0; } /* VerbatimString */ + code span.wa { color: #60a0b0; font-weight: bold; font-style: italic; } /* Warning */ @@ -22,64 +84,70 @@

1) Strings are double-quoted. Keys and chars are single-quoted.
2) Long strings belong in parentheses
3) Tabs are four spaces and spaces are ALWAYS prefered to tabs
3) Tabs are four spaces and spaces are ALWAYS preferred to tabs
4) Always add spaces between arithmetic, but never for brackets
5) EVERYTHING should be snake_case

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

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 coala since it's friendly but there' plenty of advanced linters out there.

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 }

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'
-)

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

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)

1/(2*sqrt(pi))*exp(x**2)

Do this

1 / (2 * sqrt(pi)) * exp(x ** 2)

1 / (2 * sqrt(pi)) * exp(x ** 2)

The same goes for logic operators

true & false ^ true

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

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

# 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