2015-04-28

第二回リーダブルコード勉強会を開催しました。

初めまして。エンジニアユニットの踞尾です。

今回は4月21日に第二回リーダブルコード勉強会として、再び田井先生が講談しました。


アジェンダとしては、リーダブルコードの3章から5章についてでした。

3章 誤解されない名前
    3.1 例:filter()
    3.2 例:Clip(text, length)
    3.3 限界値を含めるときはminとmaxを使う
    3.4 範囲を指定するときはfirstとlastを使う
    3.5 包含/排他的範囲にはbeginとendを使う
    3.6 ブール値の名前
    3.7 ユーザの期待に合わせる
        例:get*()
        例:list::size()
    3.8 例:複数の名前を検討する
    3.9 まとめ

4章 美しさ
    4.1 なぜ美しさが大切なのか?
    4.2 一貫性のある簡潔な改行位置
    4.3 メソッドを使った整列
    4.4 縦の線をまっすぐにする
        整列すべきなのか?
    4.5 一貫性と意味のある並び
    4.6 宣言をブロックにまとめる
    4.7 コードを「段落」に分割する
    4.8 個人的な好みと一貫性
    4.9 まとめ

5章 コメントすべきことを知る
    5.1 コメントするべきでは「ない」こと
        コメントのためのコメントをしない
        ひどい名前はコメントをつけずに名前を変える
    5.2 自分の考えを記録する
        「監督のコメンタリー」を入れる
        コードの欠陥にコメントをつける
        定数にコメントをつける
    5.3 読み手の立場になって考える
        質問されそうなことを想像する
        ハマりそうな罠を告知する
        「全体像」のコメント
        要約コメント
    5.4 ライターズブロックを乗り越える
    5.5 まとめ


雑感

普段はそこまで意識しないけれども意外と大切なことを再認識させられたり、そこまで深く考えたこともなかったと思うことも多々ありましたが、
その中でも自分が興味を持ったのが、「is, has,  can,  shouldをつけてあげて分かりやすく」っていう部分です。
勉強会では具体的な例までは出していなかったので自分なりに考えてみました。

■isを使うとき
isを使うときは「is+形容詞」「is+名詞」の形で使われることが多いのかと思います。
どのような状態かがわかるという使い方が多いですね。
isEmpty → 空の状態でtrue
isSet → 定義されていればtrue
isConnected → 接続状態でtrue
みたいな感じですね。

なので、
「isExist」
「isConnect」
みたいなのは、たまに記事などを読んでると見かけたりしますが
「is+動詞」になっていると英語的に分かりにくいのかなと思いました。

■hasを使うとき
hasは「has+過去分詞」「has+名詞」のような用途で使用すると分かり易いかと思います。
「hasChanged」 → 変更されていたらtrue
「hasValue」 → 値を持っていたらtrue
過去分詞だと時間軸的な部分も分かり易くなるので、良いですね。


■canを使うとき
canは「can+動詞」で使う機会が多そうですね。
「canDelete」 → 削除できる状態であればtrue
「canGet」 → 取得できる状態であればtrue
みたいな感じですね。

くれぐれも
「can+名詞」とか「can+形容詞」みたいなのはやめましょう。
「canStatus」「canValid」みたいな名前は混乱するので避けたいですね。

■shouldを使うとき
自分は、サーバサイドのアプリケーション作成をすることが多いのですが
あまりshouldを使った事がなくあまりイメージできなかったので、
世の人はどういう使い分けをしているのかを調査していると
Cocoa向けコーディングガイドラインに下記のような記載を発見しました。

他のオブジェクトに代わって何らかのアクションを実行するよう、デリゲートに指示するための
メソッドは、名前に「did」や「will」をつけても構いませんが、「should」の方が望ましいでしょう。
- windowShouldClose:(id)sender;
引用元:https://developer.apple.com/jp/documentation/CodingGuidelines.pdf

サーバサイドでもこういう時に使うと良いというのがあれば教えていただきたいですね。

まとめ

以上、私の雑感を長々と書かせていただきましたが、
今回の勉強会で得たことをまとめると下記のことが大事なのかなと思います。

読み手の立場になって考えられるか

書いた本人じゃない人は初めて見るソースコードになるので、初めて見る人にも分かりやすいコードを書くように心がける

コードのインデントや書き方に時間をかけ過ぎもよくない

プロジェクトのメンバー間である程度ルールを決めて、共通の認識で進める事が前提として必要

分かりにくい部分はお互い意見を交換する。

一人で分かりやすいコードを書いている気になっても結局、他のメンバーが見たときに分かりにくい部分があれば意味ないですし、他のメンバーがそもそも読みやすいコードを書く意識がない場合、プロジェクト全体で見たら可読性の低いコードになってしまうので重要

分かりやすいコードを書くことは本当に奥が深く、今まで以上に読み手の立場に立って
プログラミングをしようと感じることができた良い勉強会でした。

このエントリーをはてなブックマークに追加

0 コメント:

コメントを投稿