Slide 1
Slide 1 text
賛同者が集まらない
俺流
『リーダブルコード』
白栁 隆司
2021年1月27日
リーダブルコードLT会
Slide 2
Slide 2 text
今回の趣旨
● SESいっぱい経験しました（約20年）
● 言語やコーディングルールが変わる中で得た知見
● 白栁の個人的なコーディング哲学
● それらをまとめて「俺流リーダブルコード」
として公開します
Slide 3
Slide 3 text
自己紹介
エンジニアカウンセラー 白栁 隆司
Youtubeに平日毎日動画投稿中！ #ほぼ日ITエンジニアニュース
@IT 自分戦略研究所 エンジニアライフにて「コレがワタシの生きる様」連載中（木曜日）
４つのことを、ITエンジニアに勧めてます
1. 傾聴によるコミュニケーション
2. メンタルヘルス（セルフケア）
3. セルフマネジメント
4. 日々の生活の中からエンジニアリングを学ぶ
Slide 4
Slide 4 text
アジェンダ
1. 何故リーダブルにするか
2. 『リーダブル』のレベル
3. コードにすべてを書く必要はない
4. コードに書くべきもの
5. 『リーダブル』に正解はない
Slide 5
Slide 5 text
1. 何故リーダブルにするか
一般的に言われる「リーダルブル」な意味
● 他人が読んで理解しやすい
● メンテナンス性の向上
○ メンテナンスの工数の減少
● シンプルな方が故障率は低い
○ バグ発生頻度の減少
Slide 6
Slide 6 text
1. 何故リーダブルにするか
一般的に言われる「リーダルブル」を嫌う理由
● めんどくさい
● 意識して書いてたら手が進まない
● 自分がわかればいい
● 一定の技術力があれば読めるから問題ない
● 「リーダブル」なんてもんわからん
Slide 7
Slide 7 text
1. 何故リーダブルにするか
ある人は言った。
「このシステムは自分か触らないから、
自分だけが解るコードで書いておけばいいんだ」
さて、これでいいのでしょうか？
Slide 8
Slide 8 text
1. 何故リーダブルにするか
白柳「３日前に書いたコードは他人のコードと思え」
金曜日に書いて、月曜日に読むと意味がわからない。
そんなコードを書いた経験はありませんか？
想像してください。
半年後、一年後に書いたコードはどうなるか？
Slide 9
Slide 9 text
1. 何故リーダブルにするか
僕がリーダブルにする唯一の理由
だって、そっちの方が「めんどくさい」から。
後で読んだときに脳みそ使いたくない
Slide 10
Slide 10 text
2. 『リーダブル』のレベル
Lv0. コードが書けない人でも解る
Lv1. チーム外の人でも解る
Lv2. ベテランなら解る
Lv3. (今の)自分が解る
※白栁独自分類による
Slide 11
Slide 11 text
2. 『リーダブル』のレベル
Lv0. コードが書けない人でも解る
極論ではあるが、流石にここまでする必要はない。
コード内にコメントで仕様書の丸写しがあったり、
1行ごとにコメントが有るレベルを想定。
逆に読みにくい！！
Slide 12
Slide 12 text
2. 『リーダブル』のレベル
Lv1. チーム外の人でも解る
「チーム」とは、同じ言語・同じコーディングルールを共有す
る集団のこと。
一般的な「新人でも読めるコード」のレベル。
理想論だがここを目指したい。
Slide 13
Slide 13 text
2. 『リーダブル』のレベル
Lv2. ベテランならわかる
業務知識なり、そのチームでの開発経験なりが一定量貯
まるとスイスイ読めるようになるレベル。
一般的なコードはだいたいこの辺り。
つまり「習うより慣れろ」のケース。
Slide 14
Slide 14 text
2. 『リーダブル』のレベル
Lv3. (今の)自分が解る
もうコレは『リーダブル』とは言えない・言わない。
「自分が読めるからいいだろ」は『読める』とは言わない。
色々考えてる「今」だから解るだけ。
10年後に同じコードをすぐ理解できるか？
Slide 15
Slide 15 text
3. コードにすべてを書く必要はない
実装時に仕様書の概要をコメントで書くことはある。
（忘備録代わりになるから便利：賛否ある案件）
しかし、実装後にそれを全て残しておく必要はない。
必要な部分を残し、不要な部分は削る。
ドキュメント化用のコメント程度で十分。
Slide 16
Slide 16 text
3. コードにすべてを書く必要はない
処理の詳細を理解しやすくするために、１行ずつコメントを
書くか？ → 逆に可読性を下げる。
１行ずつ説明しないと理解できないなら、
それはロジックが悪いということ。
情報量が多すぎると可読性を下げる。
Slide 17
Slide 17 text
3. コードにすべてを書く必要はない
プログラマは「全てのコードを意識する」必要はない
システムに必要な全てのことを
「コードに落とし込む」必要はない
そして
Slide 18
Slide 18 text
3. コードにすべてを書く必要はない
ライブラリや、外部処理のことはそれらに任せる。精々「○
ライブラリに□処理を任せた」コメント。
ライブラリの問題は、ライブラリ側が解決する。
車輪の再発明は必要ないし、
なんでもやりたがる必要もない。 FW全否定かよ
Slide 19
Slide 19 text
4. コードに書くべきもの
1. ドキュメント化できるIFコメント
2. 曖昧なものを明確化する為の手がかり
a. ループ変数の命名をはっきりする
b. boolean値の省略をしない
c. 項ごとに括弧で括る
3. 忘れるもの、間違えやすいものを明記する
Javadoc とか DocComment とか
SQLだと特に有用！
Slide 20
Slide 20 text
4. コードに書くべきもの
1. ドキュメント化できるIFコメント
Javadoc や DocComment 等、APIのIFをドキュメント化で
きるもの。IDEと連動できるなら必ず書くべき！
もし、なくても処理の前に1～3行程度で書い
ておくと、とても便利。
Slide 21
Slide 21 text
4. コードに書くべきもの
2. 曖昧なものを明確化する為の手がかり
最初にコードを書いている時には意識できないもの。
後で読み返すと曖昧な意味をもつことに気付く。
予め手がかりを残しておくことで、
後で迷うことを防ぐことができる。 習慣化しよう！
多々ある。
Slide 22
Slide 22 text
4. コードに書くべきもの
2-a. ループ変数の名前をはっきりする
work や hoge 等、意味のない変数名の禁止はある。
同じことをループ変数にも適用する。
i, j, k, x, y, z 等は使わない。
idx, index は状況次第？
Slide 23
Slide 23 text
4. コードに書くべきもの
2-b. boolean値の省略をしない
True / False の2値を持つ boolean型。
この値を比較する時や演算の時は省略ができる。
T/F値を条件式に明示する。
論理否定式を使用しない。
Slide 24
Slide 24 text
4. コードに書くべきもの
2-c. 項ごとに括弧で括る
【項】とは、数式の最小単位 ※数学の項とは異なる
計算する項ごとに括弧でくくれば、演算の優先順位等の意
識を軽くできる。
SQLだととても有用！
Slide 25
Slide 25 text
4. コードに書くべきもの
3. 忘れるもの、間違えやすいものを明記する
例えば「普通ならこうする」を意図して外した処理。
「～の理由でこの処理にする」と書いておく。
例えば、条件に応じてアクセス先が変わる時。
条件とアクセス先を書いておけば確認が楽。
Slide 26
Slide 26 text
5. 『リーダブル』に正解はない
Q. 万人に読みやすい文章はありますか？
A. ありません。
文字が多く細かく書かないと分からない人がいる
絵本程度の文字量じゃないと読まない人もいる
→「日本語の文章」でもこういう感じ。
Slide 27
Slide 27 text
5. 『リーダブル』に正解はない
日本語より難しい「プログラムのコード」が
読みやすいわけがない。
所詮は個人ごとの感覚。
『リーダブル』＝幻想
Slide 28
Slide 28 text
5. 『リーダブル』に正解はない
正解がないからこそ、追い求めることができる。
完璧がないから、その場ごとに対応を変える。
他人に説明できるコードを書くこと。
常に自問自答が必要。他人の力もアテにする。
意識していれば変わる。意識することが大事！
コードレビューしてみよう！
Slide 29
Slide 29 text
まとめ
個人ごとに『リーダブル』の基準が違うのだから、
『俺流リーダブルコード』に
賛同者が集まらないのは当然だと言える！
だからといってやめるつもりはない。
今後も自分を信じて続けていくだけ。 それぞれのリーダブル！
Slide 30
Slide 30 text
ご清聴ありがとうございました
エンジニアカウンセラー
白栁 隆司
このはてしなく遠いリーダブル坂をよ...
@ShirayanagiRyuj