ITシステムの開発を主にやっています。為安圭介です。 数年間、ITシステム開発のリーダという役割をいただいて、数十名のチーム運営を経験してきました。 最近は、自分でコーディングすることがなくなってしまい、プロジェクトマネジメントや経営といった分野に携わることが多くなりました。ですが、ITエンジニアである私の仕事は、「コーディングをしてプログラムを作り、お客様に提供する」ことが基本です。ですので、常に「お客様に価値を提供するためにはどのようなプロダクトが必要なのか？」「そのプロダクトはどのように形作られるのか？」「形作るためにどのようにコーディングされるのか？」を意識しています。今回は有名な著書「リーダブルコード」をまとめながら、私のチームにとっての「良い」「悪い」を定義しました。簡単な内容ながら、見返してみると意外に深い内容になっていることに、あらためてこの書籍の意義深さを感じます。さて、このスライドをまとめるための時間は、薙刀青春マンガの最高峰、「あさひなぐ」数巻と、あとDQ11の魔王城4階までです。あさひなぐは最近映画化されましたが、声を大にして言いたい。僕はだいぶ前からこの作品の良さについて知っていたと！！わたしは弱いと言った将子、わたしは強いと言った旭の戦い。お母さんのため、自分のために一生懸命な薙と、常に全力疾走の旭のやり取り。どれも熱いです。DQ11は発売日に買ったのですが、いまだに魔王城を突破できません。メタルキングを倒すためにマルティナに槍を持たせるはずが、はぐれメタルの鎧を買うために装備品をほとんど売ってしまって一閃突きができなくなって倒せなかったことでHP（ハートポイント）を無くしてしまった（要はやる気をなくした）のが原因ですね。

1. TEAM BUILDING 39
リーダブルコード
2017.11
為安 圭介
DustinBoswell,TrevorFoucher (著)@オライリージャパン『リーダブルコード』より
私のチームの

2. 目次
1
1. 良いコードとは
2. 名前
3. 整形
4. コメント
5. 制御フローとロジック
6. 変数
7. 標準API

3. はじめに
2

4. このスライドを読んで役に立つ人
良いコードの指針を
作りたいチームリーダ
良いコードを書きたい
ITエンジニア
どちらかに当てはまるなら、
これを読めば役に立つ！
あなたはどちら？
3
・・・かもしれない！

5. 4
わたしは
紹介
為安 圭介（ためやす けいすけ）
札幌市在住のITエンジニア
仕事 企業向けWebシステムやスマホAP開発
資格 認定スクラムマスターとかプロマネとか
著書
『強いチームを作るためのたった66の方法』『1200日の朝会で学んだたったひとつのこと』
『自分のことを朕と呼んだらチームが変わった』『ブレイブ・プロジェクトマネジメント』等多数
・・・だと良いな https://www.facebook.com/keisuke.tameyasu
本スライドは、Dustin Boswell, Trevor Foucher (著) @オライリージャパン『リーダブルコード』のまとめです！

6. 本題
5

7. 1
良いコードとは

8. 7
大原則

9. 8
どっちが良いコード？
return exponent >=0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);
if (exponent >= 0) {
return mantissa * (1 << exponent);
} else {
return mantissa / (1 << -exponent);
}
（A）
（B）

10. 9
どっちが良いコード？
return exponent >=0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);
if (exponent >= 0) {
return mantissa * (1 << exponent);
} else {
return mantissa / (1 << -exponent);
}
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。

11. 10
鍵となる考え

12. ２
わかりやすい名前をつける

13. 12
どっちが良いコード？
int tmp = 0;
tmp = v[i] * v[i];
int sumSquares = 0;
sumSquares = v[i] * v[i];
（A）
（B）
ある数字の二乗を計算する値

14. 13
どっちが良いコード？
int tmp = 0;
tmp = v[i] * v[i];
int sumSquares = 0;
sumSquares = v[i] * v[i];
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
具体的な名前をつける
ある数字の二乗を計算する値

15. 14
名前がバグを教えてくれる
int tmp = 0;
tmp = v[i];
int sumSquares = 0;
sumSquares = v[i];
（A）
（B）
←これはバグ？

16. 15
名前がバグを教えてくれる
int tmp = 0;
tmp = v[i];
int sumSquares = 0;
sumSquares = v[i];
（A）
（B）
←これはバグ！
←これはバグ？
具体的な名前をつける
私のチームでは、こっちを「良いコード」と定義します。

17. 16
どっちが良いコード？
Page getPage();
Page loadPage();
（A）
（B）
ページを外部から読み込み、情報を取得する

18. 17
どっちが良いコード？
Page getPage();
Page loadPage();
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
ページを外部から読み込み、情報を取得する
具体的な名前をつける

19. 18
どっちが良いコード？
List<Person> getByName(String name);
List<Person> findByName(String name);
（A）
（B）
名前を使って、ユーザのリストを検索する

20. 19
どっちが良いコード？
List<Person> getByName(String name);
List<Person> findByName(String name);
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
名前を使って、ユーザのリストを検索する
具体的な名前をつける

21. 20
どっちが良いコード？
List<Integer> result = new ArrayList<>();
...
return result;
List<Integer> matchedIndexList = new ArrayList<>();
...
return matchedIndexList;
（A）
（B）
文字列のリストの中から、一致したindexのリストを返却する

22. 21
どっちが良いコード？
List<Integer> result = new ArrayList<>();
...
return result;
List<Integer> matchedIndexList = new ArrayList<>();
...
return matchedIndexList;
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
文字列のリストの中から、一致したindexのリストを返却する
具体的な名前をつける

23. 22
どっちが良いコード？
class LearningDate {}
class LearningStartDate{}
（A）
（B）
ある期間の開始日（例：学習期間）

24. 23
どっちが良いコード？
class LearningDate {}
class LearningStartDate{}
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
ある期間の開始日（例：学習期間）
具体的な名前をつける

25. 24
良い名前とは、誤解されない名前である
明快な単語を選ぶ
 size → height, length, bytes, memoryBytes...
 find → search,locate...
汎用的な名前を避ける
 tmp, retval → 意味のある名前に
 i, j → memberIndex, userIndex, kaishaIndex, soshikiIndex ,ki,si

26. 25
良い名前とは、誤解されない名前である
限界値などの名前は規則を決める
 上下の限界値 min, max
 包含的 first, last
 包含/排他的範囲 begin, end
誤解を招く短い名前より、わかりやすい長い名前を使う
 長い名前の入力は問題ではない ※IDEやエディタが補完してくれる
 stringをstr、documentをdocと省略するのは問題ないが、チーム独自の省略規則は
やめる

27. 3
コードは見やすく整形する

28. 27
どっちが良いコード？
public class PerformanceTester
{
public statc final TcpConnectionSimulator wifi = new TcpConnectionSimulator(
500, /*Kbps*/
80, /*msec latency*/
200,/*jitter*/
1/*packet loss %*/);
public static final TcpConnectionSimulator t3_fibar = new TcpConnectionSimulator(
45000,
10,
0,
0);
public static final TcpConnectionSimulator cell = new TcpConnectionSimulator(
100,
400,
250,
5);
}
（A）
public class PerformanceTester
{
// TcpConnectionSimulator(throughput, latency, jitter, packet_loss)
// [kbps] [ms] [ms] [%]
public statc final TcpConnectionSimulator wifi =
new TcpConnectionSimulator(500, 80, 200,1);
public static final TcpConnectionSimulator t3_fibar =
new TcpConnectionSimulator(45000, 10, 0, 0);
public static final TcpConnectionSimulator cell =
new TcpConnectionSimulator(100, 400, 250, 5);
}
（B）
4つの引数を持つTcpConnectionSimulatorクラスを使って、3つのインスタンスを作る。
1.接続速度(kbps) 2.平均遅延時間(msec) 3.遅延時間(msec) 4.パケットロス率(percent,%)

29. 28
どっちが良いコード？
public class PerformanceTester
{
public statc final TcpConnectionSimulator wifi = new TcpConnectionSimulator(
500, /*Kbps*/
80, /*msec latency*/
200,/*jitter*/
1/*packet loss %*/);
public static final TcpConnectionSimulator t3_fibar = new TcpConnectionSimulator(
45000,
10,
0,
0);
public static final TcpConnectionSimulator cell = new TcpConnectionSimulator(
100,
400,
250,
5);
}
（A）
public class PerformanceTester
{
// TcpConnectionSimulator(throughput, latency, jitter, packet_loss)
// [kbps] [ms] [ms] [%]
public statc final TcpConnectionSimulator wifi =
new TcpConnectionSimulator(500, 80, 200,1);
public static final TcpConnectionSimulator t3_fibar =
new TcpConnectionSimulator(45000, 10, 0, 0);
public static final TcpConnectionSimulator cell =
new TcpConnectionSimulator(100, 400, 250, 5);
}
（B）
4つの引数を持つTcpConnectionSimulatorクラスを使って、3つのインスタンスを作る。
1.接続速度(kbps) 2.平均遅延時間(msec) 3.遅延時間(msec) 4.パケットロス率(percent,%)
シルエットを意識する

30. 29
どっちが良いコード？
CheckFullName("doug Adams","Mr.Doglas Adams","");
CheckFullName("Jake Brown","Mr. Jake Brown III","");
CheckFullName("No such Guy","","no match found");
CheckFullName("John","","more than one result");
CheckFullName("doug Adams" ,"Mr.Doglas Adams" ,"");
CheckFullName("Jake Brown" ,"Mr. Jake Brown III" ,"");
CheckFullName("No such Guy" ,"" ,"no match found");
CheckFullName("John" ,"" ,"more than one result");
（A）
（B）

31. 30
どっちが良いコード？
CheckFullName("doug Adams","Mr.Doglas Adams","");
CheckFullName("Jake Brown","Mr. Jake Brown III","");
CheckFullName("No such Guy","","no match found");
CheckFullName("John","","more than one result");
CheckFullName("doug Adams" ,"Mr.Doglas Adams" ,"");
CheckFullName("Jake Brown" ,"Mr. Jake Brown III" ,"");
CheckFullName("No such Guy" ,"" ,"no match found");
CheckFullName("John" ,"" ,"more than one result");
（A）
（B） 私のチームでは、こっちを「良いコード」と定義・・・できるかどうか微妙。
シルエットを意識する

32. 31
一貫性と意味のあるルールでコードを整形する
複数のブロックで似たようなことをしていたら、
シルエットを揃える
 コードの「列」を揃える
並び順を揃える
 ある場所で a, b ,c と並んでいたものは、別の場所でも a, b ,c と並べる
ブロックにまとめる
 空行とコメントでブロックを「段落」に分ける

33. 書き手の意図がわかるように
コメントをつける
4

34. 33
どっちが良いコード？
// 文字列を;で分割する
String[] splitStr = str.split(“;”, 0);
String[] splitStr = str.split(“;”, 0);
（A）
（B）

35. 34
どっちが良いコード？
// 文字列を;で分割する
String[] splitStr = str.split(“;”, 0);
String[] splitStr = str.split(“;”, 0);
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
見ればわかるものをコメントしない

36. 35
どっちが良いコード？
NUM_THREADS = 8;
NUM_THREADS = 8; // 値は「num_processorsの2倍程度で十分」
（A）
（B）

37. 36
どっちが良いコード？
NUM_THREADS = 8;
NUM_THREADS = 8; // 値は「num_processorsの2倍程度で十分」
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
自分の考えを記しておく

38. 37
コメント
コメントすべきではないこと
 コードを見ればすぐにわかるようなこと
 ひどいコードを補うコメント（コードを直接修正する）
 誤解を与える表現（代名詞）
自分の考えを記録する
 なぜこの書き方なのか
 どうしてこの定数はこの値なのか
読み手の立場になる
 コードの読み手が驚くような処理はコメントしておく
 ブロック単位でコメントをつける

39. 制御フローを読みやすくする
5

40. 39
どっちが良いコード？
if (10 < length) {
if (length > 10) {
（A）
（B）
「もし10がその長さより小さいなら・・・」
「もしその長さが10より大きいなら・・・」

41. 40
どっちが良いコード？
if (10 < length) {
if (length > 10) {
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
「もし10がその長さより小さいなら・・・」
「もしその長さが10より大きいなら・・・」
変化する値を左に、固定値を右に

42. 41
どっちが良いコード？
while( 1024 > receivedBytes){
while(receivedBytes < 1024 ){
（A）
（B）

43. 42
どっちが良いコード？
while( 1024 > receivedBytes){
while(receivedBytes < 1024 ){
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
変化する値を左に、固定値を右に

44. 43
どっちが良いコード？
if (!user.hasAuthority()) {
// 権限なしの処理
} else {
// 権限ありの処理
}
if (user.hasAuthority()){
// 権限ありの処理
} else {
// 権限なしの処理
}
（A）
（B）

45. 44
どっちが良いコード？
if (!user.hasAuthority()) {
// 権限なしの処理
} else {
// 権限ありの処理
}
if (user.hasAuthority()){
// 権限ありの処理
} else {
// 権限なしの処理
}
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
if文の条件はできるだけ素直に

46. 45
どっちが良いコード？
if(userResult == true)
{
if(permissionResult != true)
{
reply.writeErrors("permissions error");
reply.done();
return;
}
}
reply.writeErrors("");
reply.done();
（A）
if (!userResult) {
reply.writeErrors(“”);
reply.done();
return;
}
if (!permissionResult) {
reply.writeErrors(“permissions error”);
reply.done();
return;
}
reply.writeErrors("");
reply.done();
（B）

47. 46
どっちが良いコード？
if(userResult == true)
{
if(permissionResult != true)
{
reply.writeErrors("permissions error");
reply.done();
return;
}
}
reply.writeErrors("");
reply.done();
（A）
if (!userResult) {
reply.writeErrors(“”);
reply.done();
return;
}
if (!permissionResult) {
reply.writeErrors(“permissions error”);
reply.done();
return;
}
reply.writeErrors("");
reply.done();
（B）
私のチームでは、こっちを
「良いコード」と定義します。
ガード節を使う

48. 47
制御フローを読みやすくする
比較を書くときは、変化する値を左に、安定した値を右に
 if (length >= 10) よりも if (10 <= length)
処理の順番
 肯定形で書く
 単純な条件を先に書く
ネストを浅く
 ガード節を使う
 特別なケースはすぐにreturn

49. 6
変数を扱いやすくする

50. 49
どっちが良いコード？
Date now = daytime.now();
System.out.println(now);
System.out.println(daytime.now());
（A）
（B）

51. 50
どっちが良いコード？
Date now = daytime.now();
System.out.println(now);
System.out.println(daytime.now());
（A）
（B） 私のチームでは、こっちを「良いコード」と定義します。
より明確にならない変数は定義しない

52. 51
どっちが良いコード？
class LargeClass{
String str;
void method1(){
str = ...;
method2();
}
void method2(){
System.println(str) ;
}
void methodOther(){
・・・
・・・
}
}
（A）
class LargeClass {
void method1() {
String str = ...;
method2(str);
}
void method2(String str) {
System.println(str) ;
}
void methodOther() {
・・・
}
}
（B）
←strを使う
←strを使う
←以降、strを使わない記述が続く
←strを使う
←strを使う
←以降のメソッドは、strが見えない

53. 52
どっちが良いコード？
class LargeClass{
String str;
void method1(){
str = ...;
method2();
}
void method2(){
System.println(str) ;
}
void methodOther(){
・・・
・・・
}
}
（A）
class LargeClass {
void method1() {
String str = ...;
method2(str);
}
void method2(String str) {
System.println(str) ;
}
void methodOther() {
・・・
}
}
（B）
私のチームでは、こっちを
「良いコード」と定義します。
←strを使う
←strを使う
←以降、strを使わない記述が続く
←strを使う
←strを使う
←以降のメソッドは、strが見えない
変数のスコープを縮める

54. 53
どっちが良いコード？
<script>
var f = function(){
for( i = 0; i < 10 ; i += 1 )...
};
f();
</script>
<script>
alert(i);
</script>
（A）
<script>
var f = function(){
for( var i = 0; i < 10 ; i += 1 )...
};
f();
</script>
<script>
alert(i);
</script>
（B）
←10が表示される ←undefined

55. 54
どっちが良いコード？
<script>
var f = function(){
for( i = 0; i < 10 ; i += 1 )...
};
f();
</script>
<script>
alert(i);
</script>
（A）
<script>
var f = function(){
for( var i = 0; i < 10 ; i += 1 )...
};
f();
</script>
<script>
alert(i);
</script>
（B）
私のチームでは、こっちを
「良いコード」と定義します。
変数のスコープを縮める
←10が表示される ←undefined

56. 55
変数
役に立たない変数は削除する
 複雑な式を分割していない変数は使わない
 より明確にならない変数は使わない
変数のスコープを縮める
 ローカル→インスタンス→グローバル
 変数のことが見えるコード行数はできるだけ減らす

57. 7
コーディング量を減らす

58. 57
鍵となる考え方

59. 58
定期的にAPIを読んで、標準ライブラリに慣れておく
標準APIを使う
汎用的なユーティリティコードを作って重複コードを
削除する
広く使われている外部ライブラリ(Apache Commons
など)にあるような機能をオレオレ実装しない

60. おわり
TEAM BUILDING 39
SpecialThanks To
S.T, A.K, E.O, S.S, T.U
Y.Y

61. 60
参考文献
• Dustin Boswell, Trevor Foucher (著) @オライリージャパン「リーダブルコード」
• 上田勲 (著)@秀和システム「プリンシプル オブ プログラミング」
• こざき亜衣@小学館「あさひなぐ」１５巻
• こざき亜衣@小学館「あさひなぐ」１６巻
• こざき亜衣@小学館「あさひなぐ」１７巻
• こざき亜衣@小学館「あさひなぐ」１８巻