@yamotongpooさんに11月はじめくらいに、「今度はRob Pike氏をよびますよ」と聞いて すごいと思っていたら、すぐあとくらいに@tenntennさんから、「キーノートを2本立てにして、片方を日本の方にということで キーノートおねがいします」という依頼がきて、Rob Pike氏と並んでキーノートなんかできるかなとややたじろぎましたが、こういうのは断るよりやっておいたほうがいい経験に なるだろうと思って具体的な内容を考えるのは後回しにして引き受けました。*1
「日本にフォーカスした話や日本のユーザがこれからGoをやっていこう！となるような内容がよいかなと思います」とのことだったので、どんな内容にするかしばらく考えていたのですが、 ふとblogを見直すとちょうど一年位前にGo Readability Approverになっていたので GoのReadabilityについて話すことにしました。Rob Pike氏はタイミング的にGo 1.4の話あたりをするんじゃないかと思っていたんです。
１年の間にレビューしたCLを見なおして、どういうコードにどういうコメントつけたのかを集めて整理しなおすだけで結構大変でした。実際多かったのは「need package comment (or doc comment)」 「error string should not be capitalized」あたりです。
CL見直して集めるのもかなり時間がかかりましたが、プレゼンで紹介しやすい短めのコードでポイントを説明できそうなやつを選ぶのもまたかなり大変でした。その後、見なおしてみたら多すぎたので講演時間におさまるようにだいぶ削りました。 実際のCLそのままはオープンソースでもないのでさすがによくなさそうだろうと思ったので、プレゼンで紹介したコードは実際のコードを元にした改変バージョンにしてあります。
タイトルは「Go Readability」にしていたのですが、当日朝会場に向かう途中にふと「郷に入っては郷に従え」がうかんできたのでした。クロージングのメッセージにしようかなと最初思いましたが、結局タイトルにすることにしました。
Rob Pike氏は予想とちがって「Simplicity is Complicated」でReadabilityとかが超大事みたいな話になっていたので、Go Readabilityの話ができたのはよかったと思います。
Goに入ってはGoに従え
-- Gopher by Renée French, and tenntenn
Goでは変数名が短くてすむ場合は短いほうがいいとされていて、これが他の言語から来た人の反発を招きやすいようですね。 でも数学で数式とか変数名はほとんど一文字なわけで、コンテキストがちゃんとわかっているのなら短くてもわかりやすいです。むしろ長いと読みにくくなりそう。
-coefficentOfLinearTeam ± sqrt(coefficientOfLinearTerm*coefficientOfLinearTerm - 4*coefficientOfSquareTerm*constantTerm) / (2*coefficientOfSquareTerm)今回のGoConの発表はGoをproductionに使ってみた系の話が多くてだいぶ普及してきたなぁと感じました。
懇親会では@jxck_さんのコードをレビューしてたんですが、Rob Pike先生から、よりエレガントなコードの手ほどきをしてもらっていました。いいコードを書くにはまだまだ修行が必要です。
後日、officeでRob Pike氏に「よいプレゼンだったから英語にも訳してよ」とリクエストされたので英語版: When in Go, do as Gophers doも作りました。 Rob Pike氏に英語のreviewもしてもらってあります。
We talk about readability all the time, but this is the first public talk I've seen explicitly on the topic and it explains things well. The examples are really good.とのお言葉をいただきました!
*1情熱プログラマにも「39: 業界で名前を売ろう Let Your Voice Be Heard」に ”名前を売り出すときに一番大事なことは、時期尚早かなと思うくらいでスタートすることだ。たいていの人は自分を売り込むときに消極的になる。君は教えるべきものを持っている。もう準備万端だと感じることは 決してない。この瞬間に始めてもいいくらいだ。"と書かれていたのを実践してみました。
