Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
開発でより良いコードを書くために
Search
gs
May 27, 2020
Programming
0
25
開発でより良いコードを書くために
pythonで開発する場合に、どのようにコードを書くべきかまとめました。
gs
May 27, 2020
Tweet
Share
More Decks by gs
See All by gs
bayesian_machine_learning 1
gggggssss
0
46
Other Decks in Programming
See All in Programming
AI時代の認知負荷との向き合い方
optfit
0
170
MUSUBIXとは
nahisaho
0
140
コマンドとリード間の連携に対する脅威分析フレームワーク
pandayumi
1
470
インターン生でもAuth0で認証基盤刷新が出来るのか
taku271
0
190
AI Schema Enrichment for your Oracle AI Database
thatjeffsmith
0
330
CSC307 Lecture 04
javiergs
PRO
0
660
Claude Codeと2つの巻き戻し戦略 / Two Rewind Strategies with Claude Code
fruitriin
0
150
[KNOTS 2026登壇資料]AIで拡張‧交差する プロダクト開発のプロセス および携わるメンバーの役割
hisatake
0
300
Oxlint JS plugins
kazupon
1
1k
登壇資料を作る時に意識していること #登壇資料_findy
konifar
4
1.7k
IFSによる形状設計/デモシーンの魅力 @ 慶應大学SFC
gam0022
1
310
Vibe Coding - AI 驅動的軟體開發
mickyp100
0
180
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.3k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
470
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.3k
Git: the NoSQL Database
bkeepers
PRO
432
66k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
55k
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
1
130
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
1.9k
Into the Great Unknown - MozCon
thekraken
40
2.3k
Principles of Awesome APIs and How to Build Them.
keavy
128
17k
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.1k
Transcript
開発でより良いコードを書くために
参考文献
変数名で中身がわかるようにする 例えばresultやgraphだけでは対象が何かわからないので、対象をつけるもしくは、 resultは使わない 例 result → detection_rate_result、total_detection_rate 例 graph →
loss_graph
導入 開発での良いコードとは ☓短いこと △最速で動くこと ◦他の人(1年後の自分含めて)が最短時間で理解できること
名前は短くしない 他の人が読んですぐに意味が理解できるように、一般的ではない、誤解を招く省略形は使わない bad examples ・gen→generate ・no → number ・epoch→ep good
examples ・directory→ dir ・maximize→max 例外・iterator→i (for i, name in enumerate(names))
関数名で処理内容がわかるようにする おすすめは def 動詞_名詞() 動詞は具体的にする 例 get_score()→calculate_score() 例 def loss_graph()
→ def draw_loass_graph()、def draw_save_loss_graph()
変数の型は書いておく intやstrと型の指定も重要だが、最低限 data frameなのか、listなのかは書いて置くとわかりやすい names_df names_list names_dic names_set names_array names
型チェックするmypy https://qiita.com/k-saka/items/8f05c89f675af219e081
単数と複数の区別を明確に イテレータでの単数と複数を明確にしておくとわかりやすい name_list = [“Mike”, “Taro”] for name in name_list:
name XXXX names_list = [“Mike”, “Taro”] for name in names_list: name XXXX
同じ変数に繰り返し違うものを代入しない 同じ変数に繰り返し違うものを代入すると中身が把握しづらくなる data = pd.read_csv(data.csv) data = f1(data) data=f2(data) total_price=f3(data)
return total_price data = pd.read_csv(data.csv) price = f1(data) price_including_tax = f2(price) total_price=f3(price_including_tax) return total_price
処理2 Detect 構造ごとにコードを分ける (class文で分けることをおすすめします) 前処理 処理1 グラフ作成 main main文 from
preprocess import Preprocess from detect import Detect from praph import Graph data = pd.read_csv(data.csv) for epoch in epochs: preprocess = Preprocess(data) detction = Detect(data) Preprocess Graph
処理2 Detect 構造ごとにコードを分ける 上位概念でまとめるとより良い 前処理 処理1 グラフ作成 main main文 from
object_detection import ObjectDtection data = pd.read_csv(data.csv) for epoch in epochs: obj = ObjectDtection(data) object_detection Preprocess Graph
フローは手書き画像のほうがわかりやすい アルゴリズムやコードの流れはコメントではなく、手書き画像が入れるのが Best ・手書きの画像をコードに入れられる VSCodeの拡張機能がある ・手書きできるデバイスが必要になる https://qiita.com/tkrkt/items/2fc9a9a59ce679aab728
PEP8に従っているかは拡張機能で確認 書いたコードがPEP8に従っているかはFlake8やBlackで自動検証すべき ・Flake8 Flake8はコードがこの規約通りに書けているか、シンタックスエラーがないかなどをチェックしてくれるツール ・Black Blackはpep8に関するエラーをチェックするだけでなく、自動で修正してくれる。さらに、改行の仕方やクォー テーションの使い方まで統一してくれる。 多人数開発でコードを合わせるのなら Blackがよい? https://www.macky-studio.com/entry/2019/07/04/152323
読みやすさも 考えないとね 人間だもの