コーディングにおける命名で気を付けていること

第3回 Cammel LT 会で登壇した時のスライド

Transcript

1. クリーンなコードを書くために 考えていること：命名編 九工大プロ研 tanacchi 1
2. tanacchi (たなっち) 九州工業大学 大学院 M1 教師なし学習の研究 九工大プロ研 初代 CTO (自称) 2 ＠q111026d twitter
3. Cammel さんとの接点 enPiT の参加校 JPHACKS 決勝で 運命の再開 りゅーと ちゃにおさん kugi さん tanacchi 3 ＠q111026d
4. 美しいコードを書こう (15min) 4 ＠q111026d
5. ATTENTION このスライドの内容は あくまで tanacchi 個人の見解であり， 所属する組織の公式見解でありません． 5 ＠q111026d
6. 美しいコードを書いていますか？ 6 ＠q111026d
7. 美しいコードの利点 • 継続的な開発 • チーム開発 • 業務の引継ぎ 2 Days ハッカソンで変なバグを踏まないためにも (最低限) きれいに書くのは必要だと思う において障害が起きにくい 7 ＠q111026d
8. 美しいコードって何だ？ 8 ＠q111026d
9. 美しいコードには種類がある(と思う) •人間の目線 •コンピュータの目線 9 ＠q111026d
10. 美しいコードの種類 •人間の目線 •コンピュータの目線 10 ＠q111026d
11. 人間目線でも様々(?) 命名 DRY の法則 拡張性と保守性 ファイルの分割 オブジェクト指向プログラミング なんやかんや 小 大 具体的 抽象的 ディレクトリ構造 11 ＠q111026d
12. 今回は命名に着目 命名 DRY の法則 拡張性と保守性 オブジェクト指向プログラミング なんやかんや 小 大 具体的 抽象的 ディレクトリ構造 ファイルの分割 12 ＠q111026d
13. 美しいコードのために 先頭からスムーズに読み進められるかどうか tanacchi の中でのポリシー 13 ＠q111026d
14. 美しいコードのために 先頭からスムーズに読み進められる 14 ＠q111026d
15. 美しいコードのために 先頭からスムーズに読み進められる 15 ＠q111026d 1. 処理の内容を先に読み進めたり 2. 戻って変数の型などを確認したり プログラムの内容を理解できる することなく，
16. 命名 Q. この関数は何を計算しますか？ 16 ＠q111026d
17. 命名 A. 数字 x の約数の和を求める関数 17 ＠q111026d
18. 何が悪いのか 1. 意味が読み取れない関数名 2. 特に必要のないコメント 4. いや知っとるわ 3. 意味を読み取りづらい変数名 18 ＠q111026d
19. 命名は大事やぞ（ニッコリ） Q. この関数は何を計算しますか？ 多少長くなっても 意図が伝わることを重視しよう 19 ＠q111026d
20. 美しいコードのために あ，約数の合計を 出すんだ～（察し） 複数形の “divisors” の方が いいよなあ 関数の中身を先に読み進めることなく 処理の内容を理解できる 20 ＠q111026d
21. 美しいコードのために 先頭からスムーズに読み進められる 21 ＠q111026d 1. 処理の内容を先に読み進めたり 2. 戻って変数の型などを確認したり プログラムの内容を理解できる することなく，
22. 他の具体例 22 ＠q111026d
23. 関数編 関数：何らかの動作を記述するもの 「 動詞 」から始まるのが自然 • set_param （パラメータを設定する） • init_status （ステータスを初期化する） 意味の伝わる範囲なら単語を省略してもいいと思う 23 ＠q111026d
24. 関数編 真偽値（true/false）を返す関数 •末尾に「?」マーク(“?”を関数名に使える言語の場合) game_finished? , available? •be動詞 か 助動詞を使う is_game_finished , can_access 24 ＠q111026d
25. 変数編 結構難しい． image という変数名 => • 画像ファイル内のRGBデータの配列？ • ファイルの名前？ • ファイルへのパス？ わからなくなったら… 前の処理を読み返して確認しなきゃいけない => 先頭からスムーズに読み進められない • rgb_array • image_filename • image_filepath 25 ＠q111026d
26. 美しいコードのために 先頭からスムーズに読み進められる 26 ＠q111026d することなく， 1. 処理の内容を先に読み進めたり 2. 戻って変数の型などを確認したり プログラムの内容を理解することができる
27. 結局何が言いたかったか 1. 多少長くなってでも伝わる命名を 2. 「関数は動詞から始める」などの慣習を 3. 人のコードを真似しながら短縮化を 以下のことを考えています これらは共通のポリシーに基づく (他人が) 先頭からスムーズに 読み進められるコードを書く 27 ＠q111026d 変数宣言のタイミング，行分けを検討するときも
28. 何をすべきか 書かなきゃ実感できないことが大半 • いろんなシチュエーションに出会いながら 自分なりの法則を見つける • チーム開発するときに コードレビューで議論するのが近道かも 28 ＠q111026d
29. おわりに 日々精進ですなあ 29 ＠q111026d