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
問題の見方を変える「システム思考」超入門
panda_program
0
170
React Nativeならぬ"Vue Native"が実現するかも?_新世代マルチプラットフォーム開発フレームワークのLynxとLynxのVue.js対応を追ってみよう_Vue Lynx
yut0naga1_fa
2
2.1k
퇴근 후 1억이 거래되는 서비스 만들기 | 내가 AI를 사용하는 방법
maryang
2
510
Verilator + Rust + gRPC と Efinix の RISC-V でAIアクセラレータをAIで作ってる話 RTLを語る会(18) 2025/11/08
ryuz88
0
320
SODA - FACT BOOK(JP)
sodainc
1
9.3k
モテるデスク環境
mozumasu
3
1.4k
自動テストを活かすためのテスト分析・テスト設計の進め方/JaSST25 Shikoku
goyoki
1
150
NIKKEI Tech Talk#38
cipepser
0
430
AI POSにおけるLLM Observability基盤の導入 ― サイバーエージェントDXインターン成果報告
hekuchan
0
400
SidekiqでAIに商品説明を生成させてみた
akinko_0915
0
120
O Que É e Como Funciona o PHP-FPM?
marcelgsantos
0
260
CSC509 Lecture 08
javiergs
PRO
0
280
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Typedesign – Prime Four
hannesfritz
42
2.9k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
660
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
8k
Designing for humans not robots
tammielis
254
26k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
Embracing the Ebb and Flow
colly
88
4.9k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
Git: the NoSQL Database
bkeepers
PRO
431
66k
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
読みやすさも 考えないとね 人間だもの