リーダブルコーディング技術スレ

**デフォルトの名無しさん** · 2013/10/11(金) 01:06:21.56

リーダブルコードとは

・読みやすさ、理解しやすさを追及したコードのことです
・読みやすいということはメンテナンス性も高いということです。
・理解しやすいコードはコードレビューも楽になります。
・理解しやすいコードはバグも少なくなります。
・短いほうが優れていることが多いですが、必ずしも短いほうがいいとは限りません。

俺ルール
・書き方の勝負であり、言語の勝負をしないでください。
・標準、非標準に限らずライブラリを使いましょう。
・なければ自分で関数を作りましょう。関数はなるべく汎用的に。

こういうコードを読みやすくするにはどうすればいいでしょうか？
というようなことを語るスレ。需要ありますかね？

**デフォルトの名無しさん** · 2013/10/11(金) 01:12:14.22

コスト感も癖にテストテスト叫ぶガキはまずリーダブルなコード書けてから言えといいたい

**デフォルトの名無しさん** · 2013/10/11(金) 01:19:10.70

最近、メインのコードから汎用的なコードを関数化していって
汎用的なコードはまあテストするが、
そうするとメインのコードが凄くシンプルになって、
それをテストするって意味あるのか？って思えてきた。

むしろテストしにくいコードをテストしなくて済むように
複雑なものを極力追いだすというか。そんな感じ。

**デフォルトの名無しさん** · 2013/10/11(金) 01:23:06.16

テストコード自体にもリーダブルさは必要だからなぁ。
リーダブルなコードを書けない人間がテストコードを書いても
ごみの集まりにしかならない。
テストのメンテナンスが大変になるだけ。

**デフォルトの名無しさん** · 2013/10/11(金) 06:39:08.19

>>1
汎用的なコードの羅列は読みにくい。コードはできるだけ個別的に書くべき。
ライブラリの使用も極力避けるべき。

**デフォルトの名無しさん** · 2013/10/11(金) 07:49:34.67

>>2
リーダブルなレス頼む

**デフォルトの名無しさん** · 2013/10/11(金) 09:03:24.36

>>5
荒らしは無視ですね。

**デフォルトの名無しさん** · 2013/10/11(金) 09:06:22.36

テストが面倒だから、テストしやすいコードを書くと簡潔になるな。
同じテストを繰り返したくないから、DRYの原則を守るようになってたり。

**デフォルトの名無しさん** · 2013/10/11(金) 10:02:12.71

>>7
pure Prolog は書き手が書いたことだけが真であって、
読み手との間で誤解の生じる余地がありません。
組込述語(ライブラリ)が無いのですから、個別的であり、
書き手と読み手の間の抽象能力の差から生じる不理解が
生じません。

**デフォルトの名無しさん** · 2013/10/11(金) 18:11:45.56

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

**デフォルトの名無しさん** · 2013/10/11(金) 22:46:36.79

>>9
問題はそれがリーダブルかどうかです。

試しにライブラリも関数も使わずにMySQLに接続して
select文を発行するコードを書いてみてくれませんか？

リーダブルコードというのは
実用的でなければなりません。

**デフォルトの名無しさん** · 2013/10/12(土) 01:48:35.10

例えばPerlでは要素が重複しないリストを返す関数はないわけ。

言語仕様だけで実装すればこんなふうになるけど、

my %count;
@array = grep( !$count{$_}++, @array ) ;

見ての通り明らかに、リーダブルではない。

List::MoreUtilsという有名なライブラリには
これをやってくれる関数がある

@array = uniq @array;

こっちの方が明らかにリーダブル。

実際の開発において、ライブラリを使わずに実装するなんてことは
腐った現場以外ありえない話なので、
リーダブルが目的の現実的な開発ではList::MoreUtilsのuniqを
使うという選択が一番正解なわけだよ。

**デフォルトの名無しさん** · 2013/10/12(土) 06:07:07.54

>>11
pure Prologではなく普通のPrologですが、
http://nojiriko.asia/prolog/fukakusa_no_shoushou_1_1.html
のようなコードを念頭に置いています。
あなたが意識されているのは読みやすさではなく実用性ではありませんか。
さすがにPrologからMySQLへのインターフェイスはないと思いますが、あれば、

　　mysql :: かやうに(_かやうに),

のように質問することになるのでしょう。

**デフォルトの名無しさん** · 2013/10/12(土) 12:17:28.70

>>13
だから実用性を考えないリーダブルに意味は無いんだって。
読んだってたかが知れてる量だとリーダブルにする意味は無いだろ。

何百、何千行にもなるような実用レベルのコードを
読みやすく構築するのがリーダブルの目標

実用レベルではMySQLを使うのは当たり前の話で
それをライブラリを使わないで書いてもリーダブルといったのはお前じゃんか。

こちとら何百、何千行もあるコードを数行に収めることを目標にしてるんだ。
だから当然ライブラリを使うし、ライブラリを作る他ないだろ。

リーダブルはあくまで実用性を念頭に置いて考えなさい。
サンプル程度の短いコードの話なんて要らないのよ。

**デフォルトの名無しさん** · 2013/10/12(土) 20:21:50.30

>>13
横レスする

もしもそのリンク先コードがリーダブルであると主張するならば、
同サイトのPrologで書かれたクイックソートのコード：
　　http://nojiriko.asia/prolog/quick_sort.html
よりも、以下のコードのほうがリーダブルであることを認めねばならない

　　クイックソート [] = []
　　クイックソート (中心軸:残りのリスト) =
　　　　　　クイックソート
　　　　　　　　中心軸未満の部分リスト ++ 中心軸:(クイックソート中心軸以上の部分リスト)
　　　　ここで
　　　　　　(中心軸未満の部分リスト, 中心軸以上の部分リスト) = リストを分割 (< 中心軸) 残りのリスト

　　リストを分割関数_f = foldr 関数_g ([], [])
　　　　ここで
　　　　　　関数_g X (部分リスト_Y, 部分リスト_Z) =
　　　　　　　　もし関数_F x ならば
　　　　　　　　　　(X:部分リスト_Y, 部分リスト_Z)
　　　　　　　　さもなくば
　　　　　　　　　　(部分リスト_Y, X:部分リスト_Z)

なお、ここでは以下を仮定した(関数型言語Haskellを元にする)架空の言語を想定している
・識別子として日本語文字(UTF-8等)が利用できる
・予約語「where」の代わりに「ここで」が利用できる
・構文「if ... then ... else ....」の代わりに「もし .... ならば .... さもなくば ....」が利用できる

**デフォルトの名無しさん** · 2013/10/12(土) 23:03:49.36

クイックソートのコードがリーダブルかなんてどうでもよくね？

qsort()

これが一番リーダブルだ。

そう難しいロジックは関数に隠蔽してしまう。

**デフォルトの名無しさん** · 2013/10/13(日) 00:05:54.29

>>16
関数抽象を言い出せば、あらゆるプログラムなんて、

program()

これが一番リーダブルだ、ってことになる

つまり>>16は、何も言明していないに等しい

**デフォルトの名無しさん** · 2013/10/13(日) 01:12:47.51

なんのプログラムかわからんだろ
頭悪すぎ

**デフォルトの名無しさん** · 2013/10/13(日) 01:29:36.94

まったくだｗ

もし>>17みたいなのがあったら、それは一つの関数で
何でもやってるリーダブルではないコードになってるだろうな。

リーダブルってのはバランス感覚が重要。
何を関数にして、何を関数にしないか。その見極めが重要。

優れた技術者は関数を汎用的なものにして
一度作ればメンテナンスを不要なレベルにする。
アプリのライフサイクルにおいて、修正が必要な箇所を極力減らす。
それがリーダブルなコードになる。

ソート関数なんてアプリの機能が変わったとしても、
一度作ればメンテナンする必要は殆ど無い。
だから関数にする。これがバランス感覚というもの。

>>17みたいなのは、結局program()の中をメンテナンスする
必要があるわけでなにも解決していない。

**デフォルトの名無しさん** · 2013/10/13(日) 01:46:35.37

それが真実とすると、整数のソート関数を作った後、文字列のソートをしたくなる。
そんな時、テンプレートが使えると理想的。
結果、C++のような変態言語が実は理想なのか？ってなってしまう。

**デフォルトの名無しさん** · 2013/10/13(日) 01:57:31.48

>>20
うん、各型ににおいて最速のコードを
生成するならC++が理想的だよ？

別にそこまでパフォーマンスが必要ないなら、
比較関数さえ入れ替え可能にしておけば
どんな型にでも対応できるけど。

**デフォルトの名無しさん** · 2013/10/13(日) 02:00:22.08

void*はリーダブルコードなのか？とか新たな疑問がわいてくる。

**デフォルトの名無しさん** · 2013/10/13(日) 02:03:46.58

void*でリーダブルかどうかなんて分かるわけがないだろ。
そもそも型であり、コードでないのだから
リーダブル”コード”の範疇外だ。

**デフォルトの名無しさん** · 2013/10/13(日) 02:05:36.89

そういうレベルまで下りてくると、関数名を適切に付けましょうとか
その程度の話になってくる。

**デフォルトの名無しさん** · 2013/10/13(日) 02:06:59.70

ちなみに俺はfunction_10000()まであと少しだが、十分リーダブル。

**デフォルトの名無しさん** · 2013/10/13(日) 02:13:43.33

>>24
重要な事なんだがねぇ。

関数の名前、関数の引数。関数の使い方。
これらがリーダブルコードの大きなカギ。

いかにメンテナンスが必要なコードを
シンプルにかつ柔軟にかけるようにするかを
提供するライブラリの構築は極めて重要な作業。

**デフォルトの名無しさん** · 2013/10/13(日) 02:17:20.26

コメントを適切につけましょう。
関数名を適切につけましょう。
当たり前の事をきちんとやりましょう。

以上でスレ終わり。

**デフォルトの名無しさん** · 2013/10/13(日) 02:18:16.83

そういう勘所わかんねえガキがすぐ喚き立てるからな。はてなダイアリーwとかツイッターwでな。滅びろガキ共

**デフォルトの名無しさん** · 2013/10/13(日) 02:18:48.07

>>28は>>26への共感

**デフォルトの名無しさん** · 2013/10/13(日) 02:18:53.68

まず、コードってのは二種類に分かれる。

アプリの仕様の変化によって
メンテナンスが必要なコードと
そうでないコード。

メンテナンスが必要でないコードの例として
フレームワークやライブラリがある。

アプリってのは何千行、何万行ものコードから
なりたっている。そのうちメンテナンスが必要なコードを
極力減らすのがリーダブルコードの重要な点。

メンテナンスが必要ないコードは汎用的であり一度覚えればよく、
中身を見る必要はないか一度だけ見れば良い。
見る必要がないコードが多ければ、コードレビューも楽になる。

見なくて良いコードを増やして、
見なくてはいけないコードを減らしていくのが
大規模アプリをリーダブルにするコツ。

**デフォルトの名無しさん** · 2013/10/13(日) 06:56:46.33

>>28
ひとつひとつのツイートをシングルクォートで囲み最後にピリオドを
付ければ、全部 Prolog プログラム。

**デフォルトの名無しさん** · 2013/10/13(日) 06:57:20.07

ﾋﾟｺｰﾝ！

関数に分ければ読む必要ないからリーダブル！
program()

**デフォルトの名無しさん** · 2013/10/13(日) 07:04:09.04

ソートが必要な場合、sort()に切り分ける。
関数名をわかりやすくsortにしておく。
ここ重要。
中身は知る必要なし。
一目で何をやってるかわかるリーダブルの完成。

**デフォルトの名無しさん** · 2013/10/13(日) 10:56:43.53

引数なし戻り値なしの関数の占める割合を見ればわかる

**デフォルトの名無しさん** · 2013/10/13(日) 12:19:10.65

>>34
お、それに気づいたか

引数なし戻り値なしの関数が
多いものは読みにくいコードであることが多い。

**デフォルトの名無しさん** · 2013/10/13(日) 20:37:38.01

んなもんただのgotoだからな

**デフォルトの名無しさん** · 2013/10/13(日) 20:43:52.86

>>15
Haskell風コードの方が当然リーダブルのように思うが、違うのか？

**デフォルトの名無しさん** · 2013/10/14(月) 06:27:13.58

>>36
いや、gosubだ

**デフォルトの名無しさん** · 2013/10/14(月) 09:03:38.99

インスタンス変数を直接触る関数は自分で書いてて分かりづらいなって思ったからやめた

**デフォルトの名無しさん** · 2013/10/15(火) 12:33:52.56

思ったよりおもしろい

**デフォルトの名無しさん** · 2013/10/15(火) 23:12:00.01

関数にすると処理があちこちに飛んで見難くなる。
だから関数を使うな。

というとんでもない意見があるが、
100%間違っているというわけでもない。

それは関数＝サブルーチンになっている場合。
コードが長いからという理由だけでその一部分を関数
（という名のサブルーチン）にした所でコードは読みやすくはならない。
なぜなら、関数の中まで読まないと何をやっているかわからないから。

ではなくて、関数というのは中を読まなくてもわかるようにするべき。
標準ライブラリの関数とか通常の開発で中を読むことはまずない。

中を読まなくていいということは、その分読む量が減るということ。
サブルーチンにした場合、その中を読まなくていいということはまずないので、
結局、あちこちに飛んで見難くなるだけ。
正しい関数の作り方を知らないからこうなる。

**デフォルトの名無しさん** · 2013/10/15(火) 23:52:26.09

1箇所からしか呼ばれないものは関数化しない、という方針は、そんなに間違ってもいないが、
絶対でもないぞ。

極端な話、初見では少々読みづらいコードになったとしても、上位レイヤと下位レイヤに
分けて実装しないと、あとあと全体の構造がメンテ不能になったりすることもある。

**デフォルトの名無しさん** · 2013/10/16(水) 00:03:18.00

>>42
レイヤ分けも「中を読まなくていいようにする」行為の一つだよ。

正しいレイヤ分けをしていれば、引数と戻り値のみがわかっていれば
そのレイヤで何を行うのかわかってるので、中のコードを読む必要がなくなる。

関数にするときは、中を読まなくていいように
なっているかどうかを意識しよう。

中を読まないといけない状態では
リーダブルにはならないことが多い。

**デフォルトの名無しさん** · 2013/10/16(水) 00:06:21.74

標準ライブラリ関数のソースは読まないけど、ドキュメントは読まないと使えないよね
>>41のいう"正しい関数の作り方"をすれば、それすらも必要ないの？
それとも、コメント書いとけっていうことを、わざわざ長文にして書いたの？

**デフォルトの名無しさん** · 2013/10/16(水) 00:14:56.17

>>44
ドキュメント≒コメントな。

同じようにコメントがあったとしても、
コードを毎回のように読まなくてはいけないものと
コードを（初回レビュー以外）読まなくても大丈夫なもの
二通り有るだろ？

コードを読まなくても大丈夫なものは、
標準ライブラリの関数などのように、
それ自体の役目が小さくサブルーチン（処理のまとまり）ではなく
しっかりと関数になっているもの。

サブルーチン（処理のまとまり）なんかだとコメントが有ったとしても
結局コードを読まないと、具体的なことは何もわからない。

どんな時だって、コメントがあれば問題解決するわけじゃないんだよ。

関数の中を毎度毎度読んでるようなら、
それは関数ではなくサブルーチンになっているということさ。
そういうのを減らせと言ってる。

**デフォルトの名無しさん** · 2013/10/16(水) 00:31:54.47

>>45
>コードを毎回のように読まなくてはいけないものと
>コードを（初回レビュー以外）読まなくても大丈夫なもの
>二通り有るだろ？
コメントでカバーできないような関数にはするなっていうこと？