It's all about time.
I can write a 4x faster program than you!
But the hardware is super powerful now,
it may be just 0.0001 ms vs. 0.0004 ms.
I can write 4x faster.
And human brain haven't changed a lot,
so it may be even 1 week vs. 1 month.
Human Time ⋙ Computer Time
Slide 3
Slide 3 text
- Benjamin Franklin
“Time is money.”
Slide 4
Slide 4 text
How to write faster?
Good language, e.g., Python
Powerful libraries
Experience
∈ The things you can't change immediately.
Slide 5
Slide 5 text
Understandable codebase.
i.e., codebase which has high maintainability.
∈ You can just learn from this share.
Slide 6
Slide 6 text
Style Guide?
# It looks okay!
count += 1
Slide 7
Slide 7 text
Not enough
# But it was initialized as
count = '1'
# In JavaScript,
# there's even no an error.
Slide 8
Slide 8 text
You remain only 10k days in your life.
Slide 9
Slide 9 text
Spend time on writing exciting feature,
not debugging.
Slide 10
Slide 10 text
Mosky
Python Charmer at Pinkoi
The author of the Python packages
MoSQL, Clime, …
The speaker of the conferences,
PyCon TW/JP/SG, …
Also teaching Python
mosky.tw
Slide 11
Slide 11 text
No content
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
Pinkoi
㫎窓磧य़戔懯珶ߝ搳ᇔ翕ᒊ
Slide 14
Slide 14 text
Pinkoi
a.k.a. 揮因ᇔጱঅ瑿ො
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
No content
Slide 17
Slide 17 text
Thanks!
Slide 18
Slide 18 text
Human Brain
Slide 19
Slide 19 text
A Computer
Read the code line by line.
Cover all of the code, usually.
Just complain when it doesn't understand.
Slide 20
Slide 20 text
A Human Brain
We can't read code like a computer.
CPU is super slow, and even can't focus.
RAM is tiny, programmer especially.
Disk is losing bytes all the time.
Nobody to complain.
So we prefer to leave code alone.
Slide 21
Slide 21 text
But, computer is always complaining.
We jump to the failed line.
Read back from the line.
Finally,
we leave immediately after we fix it.
Slide 22
Slide 22 text
Or, new requirement comes.
We still jump to the related line.
Read back from the line.
Finally,
we also leave immediately after we finish it.
Slide 23
Slide 23 text
We read lines randomly.
Slide 24
Slide 24 text
Maintainability
To understand a random line,
how many lines do you need to read back?
Lesser → Higher maintainability
Slide 25
Slide 25 text
Name
Slide 26
Slide 26 text
Nothing But
Have a good dictionary.
Be exact to avoid ambiguity.
Be consistent to avoid misleading.
Hint, hint, and hint.
Slide 27
Slide 27 text
Be Exact
“Apple”
Which “Apple”?
“Apple, the company.”
apple_the_company
Slide 28
Slide 28 text
date_a-date_b
Which dates?
today-joined_date
Slide 29
Slide 29 text
user
User’s what?
user_name
user_email
Slide 30
Slide 30 text
name
Who’s name?
user_name
store_name
Slide 31
Slide 31 text
Be Consistent
Saw this in somewhere:
apple = Company('apple')
Now you read:
apple
Then you will guess it is a company. So don't:
apple = Fruit('apple')
Slide 32
Slide 32 text
Too Long?
The context helps.
fruit.py
apple
Slide 33
Slide 33 text
Type Hint
We operate variables.
count += 1
parse(input_json)
If we know how to operate it at first glance,
it saves time from tracing or running.
Not the “Type Hint” in PEP 0484
Slide 34
Slide 34 text
Make It Intuitive
count
should be numeric
name
string thing
names
many strings; may be a list
Slide 35
Slide 35 text
page
page_no
so should be numeric
event
event_key
so should be string stuff
Slide 36
Slide 36 text
List or Set?
requested_fields & allowed_fields
?
set(requested_fileds) & allowed_field_set
Slide 37
Slide 37 text
List or Generator?
large_rows
large_rows[0] # ?
large_row_gen # generator
large_row_it # iterator
Slide 38
Slide 38 text
Object or Dict?
user
What is the type of user?
user['name'] # ?
user.name # ?
user_dict['name']
user_d['name']
Slide 39
Slide 39 text
Is it a bool?
new_user
A bool? A User instance?
is_new_user
A bool? A Function?
new
user_is_new
Slide 40
Slide 40 text
Is it a function?
Use imperative, i.e., start with a verb.
Slide 41
Slide 41 text
.text
.json
A function? A string thing?
.get_text
.parse_from_json
.text # string thing
Explicit Unknown
arg
May be tuple, dict, or anything.
arg_x
Slide 44
Slide 44 text
Avoid None
d = None if failed else {}
d['key'] = value
value = d.get('key')
It causes TypeError or AttributeError in Python,
and extra effort in other language.
Be consistent in type.
Slide 45
Slide 45 text
Some tips
Raise exception.
Use zero and infinite.
Use constant.
Filter the Nones out before return.
Slide 46
Slide 46 text
Content Type
User Input
The “Keys”
URL
JSON
HTML
SQL
∈ string thing
Slide 47
Slide 47 text
json['keyword'] # ?
Actually the json is a dict-like.
JSON: JavaScript Object Notation → a string
arg_dict = json.loads(arg_json)
Transformation
You can see the domain and codomain.
Slide 48
Slide 48 text
template.format(name)
If
template # -> "{}"
name # -> ""
!
Abstract Type
it — iterator
seq — sequence
map — mapping
Slide 51
Slide 51 text
Structure Hint
We operate the variables.
If we know how to operate it at first glance,
it saves time from tracing or running.
(Yeah, I copied it from the type hint.)
dict user_d, user_dict
list uids, uid_list
set uid_set
mapping uid_user_map
generator uid_gen
Slide 65
Slide 65 text
date start_date
datetime joined_dt
re email_re
decimal total_dec
currency
total_currency, total_ccy
total_twd
Slide 66
Slide 66 text
key → value uid_user_d_map
(x, y) uid_user_pair
[(x, y), …] uid_user_pairs
(x, y, z) uid_nick_email_tuple
Slide 67
Slide 67 text
Return Type Hint
We operate the variables.
If we know how to operate it at first glance,
it saves time from tracing or running.
(Yeah, I copied it from type hint, again.)
Slide 68
Slide 68 text
.parse
What we will get?
.parse_to_tree
Slide 69
Slide 69 text
.allow_to_log_in
Allow something to log in?
.do_allow_to_log_in
If return value is a bool, use yes–no question.
Slide 70
Slide 70 text
Performance Hint
get_name # Memory op.
parse_from_json # CPU op.
query_html
request_html # IO op.
Let reader know the roughy cost.
Slide 71
Slide 71 text
Private Hint
“Don't touch me hint”
A simple underscore prefix (_)
Don't use me out of the module or file.
Non-privates are just public APIs.
Slide 72
Slide 72 text
Hints
Type Hint
Structure Hint
Return Type Hint
Performance Hint
Private Hint
Slide 73
Slide 73 text
A random line now is more understandable.
Slide 74
Slide 74 text
Blank Line
Slide 75
Slide 75 text
Blank Line
Use blank line to separate your code into:
Paragraph
Section
Like lightweight markup language,
e.g., Markdown, RST.
Slide 76
Slide 76 text
Paragraph
Lines without any blank line.
Group similar lines into a paragraph.
Contains sub-paragraph.
Use blank line to separate paragraphs.
Slide 77
Slide 77 text
try:
html = read_html_from_cache(url)
except IOError:
html = request_html(url)
Slide 78
Slide 78 text
Section
Paragraphs.
Group similar paragraphs into a section.
Avoid sub-section.
Use two blank lines to separate sections.
Slide 79
Slide 79 text
…
Slide 80
Slide 80 text
Still don't understand?
Try to read a paragraph, then a section.
Slide 81
Slide 81 text
The “Lines”
Slide 82
Slide 82 text
Dependency
The F function calls the G function.
F depends on G.
F → G
It's a “Line”.
Slide 83
Slide 83 text
How messy?
Are the directions are all same?
Usually ↑ in a file and files.
Order your code.
Are they point to limited sections or a files?
Lesser is better.
Section or modularize them.
Slide 84
Slide 84 text
At least, easier to trace.
Slide 85
Slide 85 text
Bad Smell
Slide 86
Slide 86 text
Reality
Don't have time to refactor.
They actually work well.
Make you itch, but won't beat you.
You may already understand.
Slide 87
Slide 87 text
So Just Seal It Off
Comment the pitfalls.
Use #TODO rather than really refactor.
Assign return value to a better named variable.
Wrap them.
Just write new code.
Slide 88
Slide 88 text
Stay focused.
Slide 89
Slide 89 text
Recap
Slide 90
Slide 90 text
Recap
We read lines randomly.
Type hints and other hints
Paragraph & section by blank line.
Line your functions.
Bad smell won't beat you.
http://mosky.tw