aboutsummaryrefslogtreecommitdiffstats
path: root/templates/site/tutorials/python/py-style.html
blob: d766e3936d64eb21644933bae9e74db9fea895fd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<h1 id="coding-style-guide">Coding Style Guide</h1>
<p>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 <em>I</em> adhere to my own style because I’m terribly inconsistent</p>
<p>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.</p>
<p><em>BUT</em> first and foremost, <em>code must comply with PEP8 first</em>. This is easy to automate. I like coala since it’s friendly but there’ plenty of advanced linters out there.</p>
<p>That aside, I have the following idiosyncracies:</p>
<h2 id="strings-are-double-quoted.-keys-and-chars-are-single-quoted.">1) <em>Strings</em> are <em>double-quoted</em>. <em>Keys</em> and <em>chars</em> are <em>single-quoted</em>.</h2>
<p>This is really just because I like how C does it. And Cpython’s C-based so why not?</p>
<p>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 }</code></p>
<p>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'     )</code> That brings me to my next point.</p>
<h2 id="long-strings-belong-in-parentheses">2) Long strings belong in parentheses</h2>
<p>As in: ``` longboi = ( “This is a really long string usefull when making help menus. Be” “sure to leave s space at the end of each line, or add a new line” “when needed.”</p>
<pre><code>    &quot;Try your best to keep formatting accurate like this.&quot;
)
```</code></pre>
<h2 id="tabs-are-four-spaces-and-spaces-are-always-prefered-to-tabs">3) Tabs are four spaces and spaces are <em>ALWAYS</em> prefered to tabs</h2>
<p>Again, see PEP8.</p>
<h2 id="always-add-spaces-between-arithmetic-but-never-for-brackets">4) Always add spaces between arithmetic, but never for brackets</h2>
<p>It’s a pain to read: <code>1/(2*sqrt(pi))*exp(x**2)</code> Do this <code>1 / (2 * sqrt(pi)) * exp(x ** 2)</code> The same goes for logic operators <code>true &amp; false ^ true</code></p>
<h2 id="everything-should-be-snake_case">5) EVERYTHING should be snake_case</h2>
<p>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. ```</p>
<pre><code>user_input = int(input()) # variable
MAX_INPUT = 1000 # constant
def judge_input(_input, _max): # function
    if _max &gt; _input:
        print(&quot;Too big!&quot;)

judge_input(user_input, MAX_INPUT
class Input_Judger: # a class
    # etc etc
```</code></pre>
<p>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</code></p>