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

■ このスレッドは過去ログ倉庫に格納されています
2013/10/11(金) 01:06:21.56
リーダブルコードとは

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

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

こういうコードを読みやすくするにはどうすればいいでしょうか？
というようなことを語るスレ。需要ありますかね？
47デフォルトの名無しさん
垢版 |
2013/10/16(水) 00:42:34.63
>>46
読まないといけないコードを減らして
読まなくても良いコードに置き換えろということ。

読まなくても良いコードの割合が増えれば
それだけコードレビューの時間も減る。


コメントでカバーとかそういう発想をそもそもしていない。
コメントがなくてもコードでわかるのであれば、コメントすら不要。
コメントを書きたくなる時点で、コードがリーダブルでないという証拠でしかない。
48デフォルトの名無しさん
垢版 |
2013/10/16(水) 01:35:36.55
つまりは　なでしこで書かれたプログラムが
一番リーダブルなんじゃね？
2013/10/16(水) 01:40:12.87
噛み合ってないスレ
2013/10/16(水) 02:44:30.45
関数名と言うのは、巧いコードだと処理の概要を物語るコメントとしても機能する。
例えば void BubbleSort( int *p, int n ) という関数が何をするのかは容易に推測できる。
(ただしこんな名前でクィックソートしてるなら糞コードだが。)

一方、下手なコードだと関数名は単なる識別子としてしか機能しない。
内部で何をやっているかは関数内のコードやコメント、ドキュメントを追う必要がある。
例えば　void HogeMoge() という関数が何をするのかは中身を見なければまず分からない。

と書いてみる。
51デフォルトの名無しさん
垢版 |
2013/10/16(水) 06:06:16.25
他人のコードを読む難しさは、”作者が暗黙にイメージしてる図”を推論することの難しさにある。
f(x+d) - f(x) / d
作者自身は「これは微分するためだ」という暗黙のイメージがあるので簡単に理解できる。
一方、他人はコードのみから「これは微分が目的か？」と推論する必要がある。
コードを推論だけで読むには、作者と同等かそれ以上のコードを書けるだけの基礎が必要となる。

これら推論を補助するには、ホワイトボードによる図説が有効である。
イメージ図が有ると無いとではコード理解の難易度が大幅に変わる。
2013/10/16(水) 06:55:59.31
>>51
それこそ、 >>26 が言っている関数名の付け方の問題で、
関数名を xxxを微分する() にすれば良い。微分という
概念なら共有できるのだとすれば。
問題はこのように概念化、言語化できない(し難い)アルゴリズムの
場合、関数名では解決できないケースがあること。
5352
垢版 |
2013/10/16(水) 07:00:14.97
・・・
問題は、アルゴリズムと呼ばれているものの中には、
このような概念化、言語化できない(し難い)ものが
あり、この場合は関数名では解決できない。・・ですね。
2013/10/16(水) 07:02:42.74
「微分ってなに？」って奴に対してリーダブルにするにはどうすればいいかってことが問題になるな
55デフォルトの名無しさん
垢版 |
2013/10/16(水) 07:17:57.80
ある位置の傾き
2013/10/16(水) 08:07:51.68
>>54
それはそれで「こういう処理を微分と呼びます」でいいんじゃないの
例え新たな用語であろうと、それに対しての厳密かつ具体的な処理が示されて「こういう処理をそう呼ぶんだな」と思えないなら
プログラマとしては、数学以外の分野でもかなり困ることになるぞ
2013/10/16(水) 22:34:46.64
>>54
それは勉強すればいいことなので微分のままでいいよ。
リーダブルというのは知識不足を補うためにあるんじゃない。

会社特有の知識とか、会社やめたら無駄になるようなものは
覚える必要はまずないから、それに関するドキュメントが必要。

でも世間一般の知識は、勉強しろの一言で終わり。
それが技術力ってものだからね。

技術者である以上、自分には技術がないのでわかりません。は恥だと思え。
俺にはわからんから高度な書き方をするな。みたいなことを言ってる奴は
技術力ねぇんだなと思えばいい。自分より技術の低いやつに合わせる必要ない。
足を引っ張ってる奴が悪い。
2013/10/17(木) 00:18:54.98
道具が使えるだけの奴は三流。
技術・知識も使いこなせて二流。
人も使いこなせてこそ一流。
2013/10/17(木) 00:39:04.12
ここまでオライリーの「リーダブルコード」への言及なし。

この本のいいとこ悪いとこの話題とか、
もっと深い議論があるスレを期待した俺がバカ。
2013/10/17(木) 00:42:53.68
>>59
お前がすればいいじゃん。
他人任せなのはやめろ。
自分から行動しろ。
2013/10/17(木) 08:09:07.43
>>57
それでは足を引っ張られる一方だろ。
自分が楽をするためには
どんな馬鹿にでも判るようなやり方を使って
どんな馬鹿をも楽に使えるような環境を整えるしかない。
2013/10/18(金) 01:17:22.17
>>61
馬鹿は切り捨てるか育てるしかない。
技術者は技術があるもののことだ。
素人を基準にしてどうする？

自分が楽をしたいんだろう？
馬鹿用のやり方で楽になるわけがないだろう。
2013/10/18(金) 07:22:05.29
>>62
人事権があるならやってる。
2013/10/19(土) 10:53:36.95
じゃあ、それは人事権がないのが問題ということで。
2013/10/21(月) 18:36:53.86
リーダブル関係ねえ
66デフォルトの名無しさん
垢版 |
2013/10/21(月) 22:02:52.00
そうそう、リーダブルというのは
プロがプロのために読みやすいコードとはという話であって、
馬鹿でもわかるコードのことではない。

関数さえ理解できない馬鹿がいるんだしな。
だからそいうヤツのことを考えるのは
リーダブルとは無関係。

”リーダブルではないが”馬鹿用に仕方なく書いている。
という状態になるだけ。
2013/10/21(月) 23:11:47.66
馬鹿なんて言葉が出てくる時点でどうかと思うけどね。
2013/10/21(月) 23:13:25.52
馬鹿は切って捨てろというのは同意したいところだが、あまり理想が高すぎると誰もついて来なくなる。
そもそも原著からして「シンプルで実践的」を掲げてるわけで。
2013/10/21(月) 23:25:30.25
>>68
> 「シンプルで実践的」
って、馬鹿^H^Hプログラミング初心者に迎合しろって意味ではないだろ
7068
垢版 |
2013/10/21(月) 23:27:32.33
思うにコードを読むのにごく一部の天才しか知らない・理解できないような知識を要したり、
ごく一部の馬鹿の為に特別なルールが設けられているなどの背景についての理解を要するのは
どちらもリーダブルではない罠。

一般的なPGの大多数が、予備知識を一切持たずにすんなり読めるコードこそリーダブルと言うべきではなかろうか。
71デフォルトの名無しさん
垢版 |
2013/10/22(火) 00:26:07.90
> 思うにコードを読むのにごく一部の天才しか知らない・理解できないような知識を要したり

なんでそんなのを使うと思うんだ？

プログラミング言語が備えている機能を
普通に使ってるだけだぞ？

えとさ、例えばプロの技術者が、自分の使っている道具を
使いこなせてないとしたらどう思うよ？
72デフォルトの名無しさん
垢版 |
2013/10/22(火) 00:27:18.97
> 予備知識を一切持たずにすんなり読めるコード
そんなものはない。

技術職なんだから技術がない人間が
読めるわけ無いだろ。

反対に言えば、技術職なんだから
素人が出来ないことをできるようになれよ。
2013/10/22(火) 00:35:47.94
「PGの大多数が」を省いて我田引水おいしいです
74デフォルトの名無しさん
垢版 |
2013/10/22(火) 00:42:08.45
お前が言うPGの大多数って馬鹿のことだろう？
具体的に言えば、入社一年未満レベル。
違うのか？

本物のプログラマが普通に読めるレベルなら
プログラミング言語の機能はどれを使っても
読めるはずだが。
2013/10/22(火) 00:50:13.69
>71-72

最後に「一般的なPGの大多数が」と書いてるのに、何故そんな解釈するのさ。
言語が備えている機能を普通に使っているコードが読めないレベルが一般的で大多数だとでも?
だとしたら他を見下しすぎ。

あと「予備知識を持たずに」とは書いたけど、「勉強せずに」とは書いてないからね?
例えば余程難解な代物でも無い限り(この条件を見落とさな用に!)、コメントに「〜参照」とでも書いておくだけでも
予備知識を持たずに読めるコードになるでしょ。
2013/10/22(火) 00:54:16.90
>74
>本物のプログラマが普通に読めるレベルなら
>プログラミング言語の機能はどれを使っても
>読めるはずだが。

アセンブラでフルスクラッチできるレベルなんでしょうなぁ。
トグルスィッチでミスせず入力しきった真のPGも居ますが。
77デフォルトの名無しさん
垢版 |
2013/10/22(火) 00:54:37.35
一般的なPGの大多数がどの程度のものを指しているのかしらないけど、
例えば、プロジェクトがオープンソースプロジェクトで
多くの人が参加しているとしよう。

その予備知識を一切持たずにすんなり読めるコードに
書き換えましょうと提案して通るレベルならいいよ。
まあ少数の初心者のために書きなおすことはないだろうね。
2013/10/22(火) 00:56:14.61
>>74
PGの大多数が入社一年未満レベル？
なに言ってんの？
2013/10/22(火) 00:58:27.98
ユニバーサルデザインの考え方だな。
より一般的な、説明が不要な方法で実装したほうが、
結局はみんなが幸せよ。

例えば売掛買掛とかいう概念にしがみついてんのは、
自分の立場を守ろうとする老害よ。
専門性に逃げ込むような輩は先細っていくよ。
80デフォルトの名無しさん
垢版 |
2013/10/22(火) 01:01:20.34
おいおい、みんな結局同じことを言ってるぞ。

リーダブルコードというのは、
初心者プログラマでも読めるレベルで書くことじゃない。
プロがプロとして読みやすいコードを書くということだ。

言語の機能には時として使わないほうがいいとされる機能もあるが、
そういうものないのなら、すべて使って良い機能だ。

言語の機能を知らないのは、初心者が頑張って技術をつけろという話であって
初心者のレベルに下げようということではない。

だろ？
81デフォルトの名無しさん
垢版 |
2013/10/22(火) 01:02:49.59
>>79
> より一般的な、説明が不要な方法で実装したほうが、

より一般的な、説明が不要な方法ってなんだよ？
俺らは技術者だぜ。

技術的な方法で実装するのは問題ない。
わからないのは技術が低いからなだけだろう？
2013/10/22(火) 01:04:44.66
そもそも「初心者」っていう言葉を使ってるの一人だけっぽいが…。
我田引水っ子が混じってる気がするから気持ちよく話に参加できない。
83デフォルトの名無しさん
垢版 |
2013/10/22(火) 01:05:25.45
どんな技術でも使うことに正当な理由があれば使うし、
使うべきでは無いという正当な理由があれば使わないよ。

ただ「周りがわからないから使わない」は
正当な理由にはなりえないな。妥協した理由だ。
84デフォルトの名無しさん
垢版 |
2013/10/22(火) 01:08:07.19
>>83
なるほど。正当な理由と
妥協した理由ね。

つまりはリーダブルコードの話をする時
正当な理由のみで語るべきということ。

そこに妥協した理由を持ってきてはいけない。
妥協したいならお前の周りだけ妥協すればいいだけじゃん。
技術のなさを恥じながら妥協しておけよ。
2013/10/22(火) 01:09:50.20
>79
>より一般的な、説明が不要な方法で実装したほうが、結局はみんなが幸せよ。

この「説明が不要」と言うのはうまい表現かもね。
専門知識・用語を駆使して「説明を省く」のとはちょっと違う。
86デフォルトの名無しさん
垢版 |
2013/10/22(火) 01:14:31.11
>>85
具体的に言ってよ。

専門知識・用語を使えば簡単なのに、
使わないほうがいい例を
プログラミング技術の話でたとえてみて。
2013/10/22(火) 01:16:15.84
>>81
> より一般的な、説明が不要な方法ってなんだよ？

分からないの？
それは技術が低いから？
88デフォルトの名無しさん
垢版 |
2013/10/22(火) 01:17:05.09
>>87
いいから説明しろよ。

みんなエスパーじゃないんだからさ。
お前の考えだろ？
2013/10/22(火) 01:17:50.73
>>88
頑張って、技術をつけてくださいね;)
90デフォルトの名無しさん
垢版 |
2013/10/22(火) 01:18:19.54
>>89
くだらない煽りはいらん。
さっさと寝てろ。
91デフォルトの名無しさん
垢版 |
2013/10/22(火) 01:18:59.89
説明を求められて説明できない人って
何のために意見を言ったんだろうかね。
2013/10/22(火) 01:25:54.50
>86
>専門知識・用語を使えば簡単なのに、使わないほうがいい例

例えばC++ではないC言語で、「オブジェクト」という単語が出てきたとしよう。
本当にCをよく理解しているならそれが何を意味してるのか分かると思うが、
なまじC++等を知ってるプログラマを混乱させる元になる。
93デフォルトの名無しさん
垢版 |
2013/10/22(火) 02:12:00.61
> 例えばC++ではないC言語で、「オブジェクト」という単語が出てきたとしよう。

その場合それは専門用語ではない。
誰かが勝手に作った用語だろう？

そういう人こそちゃんと勉強して
正しい専門用語を使えと思うんだが？
2013/10/22(火) 02:20:08.94
>>63-65
合ってるだろ、leaderぶる話で
2013/10/22(火) 02:32:27.96
ぐんもー☆ぞうをなでなで
96デフォルトの名無しさん
垢版 |
2013/10/22(火) 06:28:57.24
>>88 みんなエスパーだよ?
2013/10/22(火) 07:37:14.92
関数型言語であるような、mapとかfilterとかは、
知らないと読めない典型だけど、いったん知ってしまえば
とても便利だよね
これがリーダブルなのかそうでないのかは
読み手によるとしか答えようがないなあ
2013/10/22(火) 08:40:05.16
技術の高さに頼らなくても読めないと駄目だろ
2013/10/22(火) 09:15:49.31
その言語の典型的な書き方、イディオムは、読めて当然と考えていいんじゃないか？
それをはずれた書き方は読むのをストップさせるリーダブルじゃないコードだろ。
イディオムを覚えていない初心者はこの議論の範疇外だよ。
2013/10/22(火) 21:39:53.89
クラス名や関数名、主要変数名に気を使って、ぱっと見ておおまかな処理の流れさえ分かれば、細かい処理はわかりづらくてもコメント打っておけば良いと思っている

公開する範囲にもよると思うが
101デフォルトの名無しさん
垢版 |
2013/10/22(火) 22:21:20.05
>>97
mapやfilterはものすごく勉強しないと理解できない物？
違うよね。

ちょっと知ればいい程度のものなら、勉強すれば終わりでしょ？
そんなものまで、知らないから読めないという人のために
使うかどうか迷うの？

ほんの数分の勉強で、これから先ずっと快適になるんだよ。
比べるまでもないことだよね。
2013/10/22(火) 22:57:17.67
>93
>その場合それは専門用語ではない。
>誰かが勝手に作った用語だろう？

手元にあるK&R第2版日本語訳にはこう書いてある。

【付録A(ANSI規格)】
A5 オブジェクトと左辺値
オブジェクトは名前付きのメモリ領域であり、左辺値(lvalue)はオブジェクトを参照する式である。
2013/10/22(火) 23:00:30.37
K&Rをバイブルとする技術者には御馴染み＞そのオブジェクト

>>93は頑張って勉強しなきゃな。
2013/10/22(火) 23:07:12.47
K&Rは、もはや参考書でしかないよ。
まずは規格票を読まなきゃ。
2013/10/22(火) 23:09:51.44
>104

「付録A」はその規格について述べてる訳ですが?
2013/10/22(火) 23:18:58.21
解説であって規格票そのものではないし、しかもC99じゃなくてC89のだし。
2013/10/22(火) 23:21:56.88
俺らの世代以上の人なら、K&Rの例の「オブジェクト」について、
少なくとも何度か話題に上がったことは当たり前にあるだろうね。
2013/10/22(火) 23:30:35.80
>106
まともなプログラマなら>102の内容はc99でも通用する記述だと分かるだろ
2013/10/23(水) 00:04:30.54
そもそもコードは「キーワードと文法しか知らない」コンパイラに分かるように頭から読んでいけば分かるように書いてある訳で、
どんな糞コードであっても、コンパイルが通るなら言語規格を熟知してる奴には読めるはずである。
すなわち「規格を熟知している奴に読めれば良い」という条件では糞コードを除外できない。
2013/10/23(水) 09:14:14.51
>>103
K&Rが勝手に作った用語。
2013/10/23(水) 09:58:56.67
CはそもそもK&RのRのほうが勝手に作った言語だけどなｗ
2013/10/23(水) 10:02:26.18
実に見事なニワカホイホイだった
2013/10/23(水) 10:42:04.43
小学生の口喧嘩みたいだ。
2013/10/23(水) 13:55:37.88
結局規格票で確認した奴はいなかった、というオチだろ？
2013/10/23(水) 21:15:42.29
純粋なgetter,setterじゃないのにget〜とかset〜とかは使わない方がいい？
例えば，なんかのファイルのパスを返すような関数があったとして，
getHogePath()とかいう関数名はあり？
もちろんhogeっていうメンバ変数はないとして
2013/10/23(水) 22:31:00.52
>>115
Javaの話として解釈する
ぱっと見て意味はわかるし良いと思う
所属しているクラス名がHogeなら、考え直した方がいいかも
117デフォルトの名無しさん
垢版 |
2013/10/23(水) 22:34:24.51
動的型付け言語の場合。
クラスがHogeであっても、getHogeってした方がいいよ。

なぜなら、getだけじゃ何からのgetか分からないから。
近くでnewしていれば簡単だが、関数の外から
渡されてきたらあちこちのコードを読まないとわからない。

しかも一つ見つけたら、それで正しいとは限らない。
もしかしたら見つけたのとは別のクラスも渡しているかもしれない。
2013/10/23(水) 22:52:48.88
ISO/IEC 9899:201x　Programming languages　- C
ttp://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf　24ページ目辺り

3.15
object
region of data storage in the execution environment, the contents of which can represent　values
2013/10/23(水) 22:54:38.49
「リーダブルコード」的には、getHogeはオススメされていない。
・属性値を得るだけの軽い処理とまぎらわしい
・明確じゃない（ほかの動詞を使うべき）
120デフォルトの名無しさん
垢版 |
2013/10/23(水) 22:58:55.35
内部処理を意識させないために
getでいいのでは？

内部処理がどうなっているか不明なのだから
軽いかどうかなんてわかり用がないし
変わることだってだろう？

そこに何かの想定をしてはいけないだけの話。
2013/10/23(水) 23:02:09.66
>>120が英語が出来ないだけの話
リーダブルコードの意味をもう一度考えたほうがいい
2013/10/23(水) 23:09:46.14
Foo.getHoge(); と書くと「FooがHogeをgetする」になってしまう罠。

仮にこれを「FooからHogeをgetする」と読むのならば、
if( Foo.isHoge() ) を 「もしFooがHogeなら」と読めなくなる。
2013/10/23(水) 23:16:32.20
そのロジックはこじつけすぎ
慣習には従うべき
124122
垢版 |
2013/10/23(水) 23:19:31.79
間違えてUCCで書いてもうた…orz
でもまぁ標準ライブラリでもよく考えるとおかしなのがあるから、あまり気にせずとも良い気も。
2013/10/23(水) 23:20:41.94
>>115
定数オーダーの処理ならget,setって言っていいイメージでいます。
2013/10/23(水) 23:31:43.97
話が逸れるけど関数名だけに拘るのではなく、戻り値や引数の型その他を含むシグネチャ全体に気を使った方が良いかと。
特にC/C++なんかだとconstの有無はネーミングと同じ位気を使って欲しい。
うまく使えば読みやすくなるし。
2013/10/23(水) 23:31:45.03
そのHogePathの出どころによるよね
DBから探してくるならfindHogePathとかsearchForHogePath
コンポーネントをいくつか組み合わせて作るならcomposeHogePath
どこかに設定してあるのをちゃちゃっと取ってくるだけならgetHogePath
処理の中身がわかる名前がいいと思うよ
2013/10/24(木) 01:34:22.78
>>122
> Foo.getHoge(); と書くと「FooがHogeをgetする」になってしまう罠。

つまりgetは一切使うなってこと？

いや違うな。Fooをcreateしてしまう場合は、create Fooだろう？
Foo.createだったら、Fooが作成してしまうになってしまう。

いやいやcreateではなく、newだからnew Fooであってるのか。
Foo.newはだめだな。

でもこれはnewだけの話だろう？

Array.join(', ')とかどうなるんだ？配列が','でjoinする？
配列をjoinするんじゃないのか？

おかしいな。

とりえず俺としての結論は、
Foo.isHogeがたまたまそう読めるからといって、だからなに？
他は違う読み方をすればいいだけじゃない。
ってことだな。
2013/10/24(木) 01:49:19.21
>>128
RubyではFoo.newなんだが（；＾ω＾）
2013/10/24(木) 03:46:48.68
>>129
だから>>122はおかしいってことでしょ
2013/10/24(木) 07:03:23.93
>>129
それは一文字でも短くタイプするとかいう変な宗教だろう
リーダブルとは真逆
2013/10/24(木) 09:16:09.11
Foo.new と new Foo の違いは、前者がメタオブジェクト（Classのインスタンス）の
インスタンスメソッドの呼び出しであるのに対し、後者がnewという前置演算子による
演算子式である、という意味の違いが構文の違いになっているに過ぎず、
リーダビリティとは全く何の関係もない。

それを「一文字でも短くタイプするとかいう変な宗教」とか考える奴の脳味噌が変。
2013/10/24(木) 09:45:45.73
言いたい事をほぼ>>132が言ってくれたから話が早いｗ
2013/10/24(木) 10:17:04.85
>>131
一文字でも短くタイプするとかいう変な宗教とは、
Foo()
と書くリーダブブルとは真逆な某言語のことだろw
2013/10/24(木) 10:18:18.30
>>134
俺 Python スレとシャワートイレ板で有名コテやってるかあんまり怒らせないほうがいいよ
2013/10/24(木) 10:56:44.27
>>134
これ一番分かりやすいな
2013/10/24(木) 12:52:43.82
その言語において、コンストラクタが普通の関数と同じものなら、それで問題ない。

プログラミング言語は、計算のための意味論を持った、形式言語である、という前提を外した
議論からは、何も生まれないよ。
2013/10/24(木) 21:30:48.46
>>134
Perlは Foo だけでいけるよ。
2013/10/24(木) 21:33:14.24
>>134
なんでリーダブルとは間逆なの？

極端に短く書いたらリーダブルじゃなくなるけど、
適度に短いのはリーダブルだよね？
2013/10/24(木) 21:41:37.23
>>134みたいな馬鹿に賛同する奴は
本当に馬鹿なんだろうなって
心の底から思うよ。
2013/10/24(木) 21:52:44.97
というより、ちょっと前から一人おかしい子が紛れ込んでる希ガスｗ
知ったようなことを言いたいんだ、ということだけ分かる。
2013/10/24(木) 22:02:24.23
こんな感じで分かり易いコード書けるよー、的な話題になると、
気の利いたコード書けない低脳が、そんなの関数化するから関係無いと言い出し、
その結果、関数名とか変数名とか、あとメソッド呼び出しでの括弧省略とか、
そういう下らない議論になる

読んでないけど、このスレもそんな感じですか？
2013/10/24(木) 22:05:39.81
あぁ、お前が読んでないことが2行目でわかったよｗ
さっさと自分のスレに帰って、
そいつに泣かされてこい。
2013/10/24(木) 22:08:26.25
自分のスレとか言い出したら
病気ですよ
2013/10/24(木) 22:11:41.26
>>144
？
2013/10/24(木) 22:12:24.79
あ、馬鹿にしたことに気づいてないのかｗ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。