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

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

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

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

こういうコードを読みやすくするにはどうすればいいでしょうか？
というようなことを語るスレ。需要ありますかね？
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
あ、馬鹿にしたことに気づいてないのかｗ
2013/10/24(木) 22:25:41.04
自分のスレって何だ？
148デフォルトの名無しさん
垢版 |
2013/10/24(木) 22:30:08.34
三人称単数ならgetsだろ藁（）
小学生かお前ら核爆（）
2013/10/24(木) 22:40:56.38
>148
メンバからの呼び出しの場合
2013/10/24(木) 23:07:37.25
>>139
new Foo や Foo.new は「適度に短い」からリーダブルだよ
なぜなら、new というキーワードによって、単なるメソッド呼び出しと
コンストラクタ呼び出しを一目で見分けられる、
つまりコードリーディングを配慮した言語設計だと言える

それに対して、Foo() は「極端に短い」からアンリーダブルだね
なぜなら、前後の文脈を確認しなければ、それがメソッド呼び出しなのか
コンストラクタ呼び出しなのかが区別できない
つまりコードリーディングを無視した
「一文字でも短くタイプするとかいう変な宗教(>>131)」に従った言語設計だと言える

たとえば、f() というコードは一見するとメソッド(または関数)呼び出しに見える
しかし、その前の文脈に f = Foo があれば、f() の意味はコンストラクタ呼び出しになる
もしも、これが new f または f.new であれば迷うこと無くコンストラクタであると判断できる
2013/10/24(木) 23:09:12.24
> それに対して、Foo() は「極端に短い」からアンリーダブルだね

なんで？ Foo()という関数は読みづらいか？
2013/10/24(木) 23:10:31.80
ていうか、何でコンストラクタと普通の関数を区別する必要があるの？
馬鹿なの？
2013/10/24(木) 23:11:09.04
メソッドとかコンストラクタと言ってる時点で
わかってないやつじゃないか。

このスレで言う、リーダブルとは
技術の低いやつに合わせることではないって
話と同じことだな。
2013/10/24(木) 23:11:54.80
newFoo = Fooって書けばよくね???
2013/10/24(木) 23:18:11.87
アホがアホのフリをする必要は無いぞ。
156デフォルトの名無しさん
垢版 |
2013/10/24(木) 23:31:48.54
そもそもオブジェクト指向とかゴミだろ藁（）
OCaml最高！！
2013/10/24(木) 23:37:35.84
Objective Caml ........
2013/10/24(木) 23:38:57.24
第一級のモジュールができて
完全にオワコンになったOCamlのO
2013/10/24(木) 23:40:51.03
一時のブームに流されたばかりに.....
2013/10/24(木) 23:41:59.24
おまえら、ここは言語の勝負するスレじゃないぞ
2013/10/24(木) 23:47:53.68
if !flag vs. unless flag 派のたたかいはまだですか
2013/10/24(木) 23:50:39.18
論理的にはどちらか一方あればいいけど、
読むことを考えれば、両方できる方がいい。
2013/10/24(木) 23:51:21.06
のってやろう
俺は!を見逃すという凡ミスでハマったゴミクソ野郎なので
unless派だ
2013/10/24(木) 23:52:16.44
実装は同じになるけど、英語の意味は違うよ
だから両方ある方がいい
2013/10/25(金) 01:24:29.19
if not でいいじゃん
2013/10/25(金) 10:07:22.11
条件式は明示的に比較演算子を記述すること
2013/10/25(金) 10:22:07.23
俺みたいな雑魚が until と unless を間違えるから、どちらかを別の単語にすべきだ。
2013/10/25(金) 11:01:11.16
if修飾子が好き。
条件の文字をxで置き換えて書くと

next if xxxxxx
next if xxxxxxxxxxxx
next if xxx

と揃っていて美しい。一瞬でこの一群の目的が分かる。
旧来の方法だと、

if (xxxxxx) next
if (xxxxxxxxxxxx) next
if (xxx) next

こうなって、この一群が同一の目的を持ってることがスグには分からない。
2013/10/25(金) 11:35:26.92
>>168
すみません。このnextっていうのは何のことですか？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況