Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
命名の話
@moznion
すべての人物・事物には
真の名前があり、
その名前を知るものは
それを支配することができる
名前重要
我々はどのようにして
名前を付けるのか
method/func の場合
動詞から始めよ
(e.g. isValid, fetchUserName)
どちらが良いか?
(isValidXXX() or validateXXX())
それが何をするのか
何を返すのかで変わる
どちらが良いか?
(isValidXXX() or validateXXX())
validation した結果だけ返す

だいたい bool が来る
どちらが良いか?
(isValidXXX() or validateXXX())
validation する
何が返るかわからない
その者が何者であるか
(何をするか)
で名前を決める
逆にその者が何者であるかは
名前によって決定される
言霊 the Power
variable の場合
名詞であるべき
(e.g. id, grantedName)
形容詞・副詞は名詞の前に
付けたほうが個人的に良いと
思っている
基本的に動詞が入ることは
起こりえない (はず)
型情報を名前で表すべきか
問題
例えばハンガリアン記法
(e.g. sFileName, epochI)
例えばハンガリアン記法
(e.g. sFileName, epochI)
ナツい!
とは言え,urlString みたいな
名前を付けることはある
あと,配列とかListだったら
複数形にするとかですね
(複数形にする派です)
動的型付け: 型情報をちょっと
は書いても良いのでは
(ハンガリアンが良いとは
言っていない)
静的型付け: 型情報見れば済む
から詳しく書く必要はないや
ろ,各自やっていけ
Class の場合
名詞であるべき
(e.g. URLEncoder, fbAuthenticator)
Roll を的確に表した語を
名づけてやる必要がある
変数名よりも
純粋な名詞的ネーミングに
なる傾向がある気がする
(修飾語が少ない)
URL の場合
名詞であるべき
あと基本的に1単語で
(RESTっぽい!!!!!)
とは言え動詞が入ることが
ありますね
動詞の方がわかりやすいこと
もある (signupとかね)
☑各自やっていく必要あり
このあたり
Web API: The Good Parts
が参考になる気がします
雑な話題
短い名前 VS 長い名前
短い名前
- 打ちやすい
- コードの見通しが良くなる場合有
- 意味不明になる可能性がある
- 大きなスコープを防ぐための

抑止力になりえる
長い名前
- 打ちにくい
- コードの見通しがゴチャっと

する場合がある
- 説明的な名前に出来るので

役割を一目で理解できること多い
- 適度な長さでやる (各自の意識)
- URL とかは短いほうが良い

エンカウント機会!!!!
- 最低限かつ不足のない名前を

付ける (コメントが要るか要らな
いかが指標となる)
- IDE を使っていけ (補完が効く)
どうすりゃいい...
情報が無いところから
情報を生み出すことは出来ない
情報にあふれたところから
情報を蒸留することは出来る
困ったらとりあえず
長い名前付けておくのが
良い,悩む時間が勿体無い
命名に
詰まったら他人と
議論する
snake_case VS CamelCase
言語のコーディング規約に
従うと吉
とは言え基本的に
CamelCaseは読みにくいですね
(Java批判ではないです)
CamelCaseが読みにくい
っつうのも
なんかの論文でデータとして
出ていたはず
(論文を忘れたので引用できない)
snake_case 使えるところは
使っていけば良いのでは……
コーディングの労力に
おいて命名の占める
割合は大きいので
(良し悪しが大きく左右される)
各位頑張りましょう
Upcoming SlideShare
Loading in …5
×

命名の話

2,748 views

Published on

命名の話です

Published in: Technology
  • If you want to download or read this book, copy link or url below in the New tab ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m6jJ5M } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

命名の話

  1. 1. 命名の話 @moznion
  2. 2. すべての人物・事物には 真の名前があり、 その名前を知るものは それを支配することができる
  3. 3. 名前重要
  4. 4. 我々はどのようにして 名前を付けるのか
  5. 5. method/func の場合
  6. 6. 動詞から始めよ (e.g. isValid, fetchUserName)
  7. 7. どちらが良いか? (isValidXXX() or validateXXX())
  8. 8. それが何をするのか 何を返すのかで変わる
  9. 9. どちらが良いか? (isValidXXX() or validateXXX()) validation した結果だけ返す
 だいたい bool が来る
  10. 10. どちらが良いか? (isValidXXX() or validateXXX()) validation する 何が返るかわからない
  11. 11. その者が何者であるか (何をするか) で名前を決める
  12. 12. 逆にその者が何者であるかは 名前によって決定される
  13. 13. 言霊 the Power
  14. 14. variable の場合
  15. 15. 名詞であるべき (e.g. id, grantedName)
  16. 16. 形容詞・副詞は名詞の前に 付けたほうが個人的に良いと 思っている
  17. 17. 基本的に動詞が入ることは 起こりえない (はず)
  18. 18. 型情報を名前で表すべきか 問題
  19. 19. 例えばハンガリアン記法 (e.g. sFileName, epochI)
  20. 20. 例えばハンガリアン記法 (e.g. sFileName, epochI) ナツい!
  21. 21. とは言え,urlString みたいな 名前を付けることはある
  22. 22. あと,配列とかListだったら 複数形にするとかですね (複数形にする派です)
  23. 23. 動的型付け: 型情報をちょっと は書いても良いのでは (ハンガリアンが良いとは 言っていない)
  24. 24. 静的型付け: 型情報見れば済む から詳しく書く必要はないや ろ,各自やっていけ
  25. 25. Class の場合
  26. 26. 名詞であるべき (e.g. URLEncoder, fbAuthenticator)
  27. 27. Roll を的確に表した語を 名づけてやる必要がある
  28. 28. 変数名よりも 純粋な名詞的ネーミングに なる傾向がある気がする (修飾語が少ない)
  29. 29. URL の場合
  30. 30. 名詞であるべき あと基本的に1単語で (RESTっぽい!!!!!)
  31. 31. とは言え動詞が入ることが ありますね 動詞の方がわかりやすいこと もある (signupとかね)
  32. 32. ☑各自やっていく必要あり
  33. 33. このあたり Web API: The Good Parts が参考になる気がします
  34. 34. 雑な話題
  35. 35. 短い名前 VS 長い名前
  36. 36. 短い名前 - 打ちやすい - コードの見通しが良くなる場合有 - 意味不明になる可能性がある - 大きなスコープを防ぐための
 抑止力になりえる
  37. 37. 長い名前 - 打ちにくい - コードの見通しがゴチャっと
 する場合がある - 説明的な名前に出来るので
 役割を一目で理解できること多い
  38. 38. - 適度な長さでやる (各自の意識) - URL とかは短いほうが良い
 エンカウント機会!!!! - 最低限かつ不足のない名前を
 付ける (コメントが要るか要らな いかが指標となる) - IDE を使っていけ (補完が効く) どうすりゃいいのさ
  39. 39. 情報が無いところから 情報を生み出すことは出来ない 情報にあふれたところから 情報を蒸留することは出来る
  40. 40. 困ったらとりあえず 長い名前付けておくのが 良い,悩む時間が勿体無い
  41. 41. 命名に 詰まったら他人と 議論する
  42. 42. snake_case VS CamelCase
  43. 43. 言語のコーディング規約に 従うと吉
  44. 44. とは言え基本的に CamelCaseは読みにくいですね (Java批判ではないです)
  45. 45. CamelCaseが読みにくい っつうのも なんかの論文でデータとして 出ていたはず (論文を忘れたので引用できない)
  46. 46. snake_case 使えるところは 使っていけば良いのでは……
  47. 47. コーディングの労力に おいて命名の占める 割合は大きいので (良し悪しが大きく左右される) 各位頑張りましょう

×