リーダブルコーディング技術スレ (187)
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▼
C言語なら俺に聞け(入門編)Part 121 (201)
静的型付け言語の潜在開発生産性は今の100倍 ×3 (561)
JAVAってこんなことも出来ないの? (695)
【C++】マイナーGUIツールキット (686)
C言語なら俺に聞け(入門編)Part 121 (201)
プログラミングを勉強したいのだが (141)
リーダブルコーディング技術スレ
1 :2013/10/11 〜 最終レス :2013/10/26 リーダブルコードとは ・読みやすさ、理解しやすさを追及したコードのことです ・読みやすいということはメンテナンス性も高いということです。 ・理解しやすいコードはコードレビューも楽になります。 ・理解しやすいコードはバグも少なくなります。 ・短いほうが優れていることが多いですが、必ずしも短いほうがいいとは限りません。 俺ルール ・書き方の勝負であり、言語の勝負をしないでください。 ・標準、非標準に限らずライブラリを使いましょう。 ・なければ自分で関数を作りましょう。関数はなるべく汎用的に。 こういうコードを読みやすくするにはどうすればいいでしょうか? というようなことを語るスレ。需要ありますかね?
2 : コスト感も癖にテストテスト叫ぶガキはまずリーダブルなコード書けてから言えといいたい
3 : 最近、メインのコードから汎用的なコードを関数化していって 汎用的なコードはまあテストするが、 そうするとメインのコードが凄くシンプルになって、 それをテストするって意味あるのか?って思えてきた。 むしろテストしにくいコードをテストしなくて済むように 複雑なものを極力追いだすというか。そんな感じ。
4 : テストコード自体にもリーダブルさは必要だからなぁ。 リーダブルなコードを書けない人間がテストコードを書いても ごみの集まりにしかならない。 テストのメンテナンスが大変になるだけ。
5 : >>1 汎用的なコードの羅列は読みにくい。コードはできるだけ個別的に書くべき。 ライブラリの使用も極力避けるべき。
6 : >>2 リーダブルなレス頼む
7 : >>5 荒らしは無視ですね。
8 : テストが面倒だから、テストしやすいコードを書くと簡潔になるな。 同じテストを繰り返したくないから、DRYの原則を守るようになってたり。
9 : >>7 pure Prolog は書き手が書いたことだけが真であって、 読み手との間で誤解の生じる余地がありません。 組込述語(ライブラリ)が無いのですから、個別的であり、 書き手と読み手の間の抽象能力の差から生じる不理解が 生じません。
10 : このスレッドは天才チンパンジー「アイちゃん」が 言語訓練のために立てたものです。 アイと研究員とのやり取りに利用するスレッドなので、 関係者以外は書きこまないで下さい。 京都大学霊長類研究所
11 : >>9 問題はそれがリーダブルかどうかです。 試しにライブラリも関数も使わずにMySQLに接続して select文を発行するコードを書いてみてくれませんか? リーダブルコードというのは 実用的でなければなりません。
12 : 例えばPerlでは要素が重複しないリストを返す関数はないわけ。 言語仕様だけで実装すればこんなふうになるけど、 my %count; @array = grep( !$count{$_}++, @array ) ; 見ての通り明らかに、リーダブルではない。 List::MoreUtilsという有名なライブラリには これをやってくれる関数がある @array = uniq @array; こっちの方が明らかにリーダブル。 実際の開発において、ライブラリを使わずに実装するなんてことは 腐った現場以外ありえない話なので、 リーダブルが目的の現実的な開発ではList::MoreUtilsのuniqを 使うという選択が一番正解なわけだよ。
13 : >>11 pure Prologではなく普通のPrologですが、 http://nojiriko.asia/prolog/fukakusa_no_shoushou_1_1.html のようなコードを念頭に置いています。 あなたが意識されているのは読みやすさではなく実用性ではありませんか。 さすがにPrologからMySQLへのインターフェイスはないと思いますが、あれば、 mysql :: かやうに(_かやうに), のように質問することになるのでしょう。
14 : >>13 だから実用性を考えないリーダブルに意味は無いんだって。 読んだってたかが知れてる量だとリーダブルにする意味は無いだろ。 何百、何千行にもなるような実用レベルのコードを 読みやすく構築するのがリーダブルの目標 実用レベルではMySQLを使うのは当たり前の話で それをライブラリを使わないで書いてもリーダブルといったのはお前じゃんか。 こちとら何百、何千行もあるコードを数行に収めることを目標にしてるんだ。 だから当然ライブラリを使うし、ライブラリを作る他ないだろ。 リーダブルはあくまで実用性を念頭に置いて考えなさい。 サンプル程度の短いコードの話なんて要らないのよ。
15 : >>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 ....」の代わりに「もし .... ならば .... さもなくば ....」が利用できる
16 : クイックソートのコードがリーダブルかなんてどうでもよくね? qsort() これが一番リーダブルだ。 そう難しいロジックは関数に隠蔽してしまう。
17 : >>16 関数抽象を言い出せば、あらゆるプログラムなんて、 program() これが一番リーダブルだ、ってことになる つまり>>16 は、何も言明していないに等しい
18 : なんのプログラムかわからんだろ 頭悪すぎ
19 : まったくだw もし>>17 みたいなのがあったら、それは一つの関数で 何でもやってるリーダブルではないコードになってるだろうな。 リーダブルってのはバランス感覚が重要。 何を関数にして、何を関数にしないか。その見極めが重要。 優れた技術者は関数を汎用的なものにして 一度作ればメンテナンスを不要なレベルにする。 アプリのライフサイクルにおいて、修正が必要な箇所を極力減らす。 それがリーダブルなコードになる。 ソート関数なんてアプリの機能が変わったとしても、 一度作ればメンテナンする必要は殆ど無い。 だから関数にする。これがバランス感覚というもの。 >>17 みたいなのは、結局program()の中をメンテナンスする 必要があるわけでなにも解決していない。
20 : それが真実とすると、整数のソート関数を作った後、文字列のソートをしたくなる。 そんな時、テンプレートが使えると理想的。 結果、C++のような変態言語が実は理想なのか?ってなってしまう。
21 : >>20 うん、各型ににおいて最速のコードを 生成するならC++が理想的だよ? 別にそこまでパフォーマンスが必要ないなら、 比較関数さえ入れ替え可能にしておけば どんな型にでも対応できるけど。
22 : void*はリーダブルコードなのか?とか新たな疑問がわいてくる。
23 : void*でリーダブルかどうかなんて分かるわけがないだろ。 そもそも型であり、コードでないのだから リーダブル”コード”の範疇外だ。
24 : そういうレベルまで下りてくると、関数名を適切に付けましょうとか その程度の話になってくる。
25 : ちなみに俺はfunction_10000()まであと少しだが、十分リーダブル。
26 : >>24 重要な事なんだがねぇ。 関数の名前、関数の引数。関数の使い方。 これらがリーダブルコードの大きなカギ。 いかにメンテナンスが必要なコードを シンプルにかつ柔軟にかけるようにするかを 提供するライブラリの構築は極めて重要な作業。
27 : コメントを適切につけましょう。 関数名を適切につけましょう。 当たり前の事をきちんとやりましょう。 以上でスレ終わり。
28 : そういう勘所わかんねえガキがすぐ喚き立てるからな。はてなダイアリーwとかツイッターwでな。滅びろガキ共
29 : >>28 は>>26 への共感
30 : まず、コードってのは二種類に分かれる。 アプリの仕様の変化によって メンテナンスが必要なコードと そうでないコード。 メンテナンスが必要でないコードの例として フレームワークやライブラリがある。 アプリってのは何千行、何万行ものコードから なりたっている。そのうちメンテナンスが必要なコードを 極力減らすのがリーダブルコードの重要な点。 メンテナンスが必要ないコードは汎用的であり一度覚えればよく、 中身を見る必要はないか一度だけ見れば良い。 見る必要がないコードが多ければ、コードレビューも楽になる。 見なくて良いコードを増やして、 見なくてはいけないコードを減らしていくのが 大規模アプリをリーダブルにするコツ。
31 : >>28 ひとつひとつのツイートをシングルクォートで囲み最後にピリオドを 付ければ、全部 Prolog プログラム。
32 : ピコーン! 関数に分ければ読む必要ないからリーダブル! program()
33 : ソートが必要な場合、sort()に切り分ける。 関数名をわかりやすくsortにしておく。 ここ重要。 中身は知る必要なし。 一目で何をやってるかわかるリーダブルの完成。
34 : 引数なし戻り値なしの関数の占める割合を見ればわかる
35 : >>34 お、それに気づいたか 引数なし戻り値なしの関数が 多いものは読みにくいコードであることが多い。
36 : んなもんただのgotoだからな
37 : >>15 Haskell風コードの方が当然リーダブルのように思うが、違うのか?
38 : >>36 いや、gosubだ
39 : インスタンス変数を直接触る関数は自分で書いてて分かりづらいなって思ったからやめた
40 : 思ったよりおもしろい
41 : 関数にすると処理があちこちに飛んで見難くなる。 だから関数を使うな。 というとんでもない意見があるが、 100%間違っているというわけでもない。 それは関数=サブルーチンになっている場合。 コードが長いからという理由だけでその一部分を関数 (という名のサブルーチン)にした所でコードは読みやすくはならない。 なぜなら、関数の中まで読まないと何をやっているかわからないから。 ではなくて、関数というのは中を読まなくてもわかるようにするべき。 標準ライブラリの関数とか通常の開発で中を読むことはまずない。 中を読まなくていいということは、その分読む量が減るということ。 サブルーチンにした場合、その中を読まなくていいということはまずないので、 結局、あちこちに飛んで見難くなるだけ。 正しい関数の作り方を知らないからこうなる。
42 : 1箇所からしか呼ばれないものは関数化しない、という方針は、そんなに間違ってもいないが、 絶対でもないぞ。 極端な話、初見では少々読みづらいコードになったとしても、上位レイヤと下位レイヤに 分けて実装しないと、あとあと全体の構造がメンテ不能になったりすることもある。
43 : >>42 レイヤ分けも「中を読まなくていいようにする」行為の一つだよ。 正しいレイヤ分けをしていれば、引数と戻り値のみがわかっていれば そのレイヤで何を行うのかわかってるので、中のコードを読む必要がなくなる。 関数にするときは、中を読まなくていいように なっているかどうかを意識しよう。 中を読まないといけない状態では リーダブルにはならないことが多い。
44 : 標準ライブラリ関数のソースは読まないけど、ドキュメントは読まないと使えないよね >>41 のいう"正しい関数の作り方"をすれば、それすらも必要ないの? それとも、コメント書いとけっていうことを、わざわざ長文にして書いたの?
45 : >>44 ドキュメント≒コメントな。 同じようにコメントがあったとしても、 コードを毎回のように読まなくてはいけないものと コードを(初回レビュー以外)読まなくても大丈夫なもの 二通り有るだろ? コードを読まなくても大丈夫なものは、 標準ライブラリの関数などのように、 それ自体の役目が小さくサブルーチン(処理のまとまり)ではなく しっかりと関数になっているもの。 サブルーチン(処理のまとまり)なんかだとコメントが有ったとしても 結局コードを読まないと、具体的なことは何もわからない。 どんな時だって、コメントがあれば問題解決するわけじゃないんだよ。 関数の中を毎度毎度読んでるようなら、 それは関数ではなくサブルーチンになっているということさ。 そういうのを減らせと言ってる。
46 : >>45 >コードを毎回のように読まなくてはいけないものと >コードを(初回レビュー以外)読まなくても大丈夫なもの >二通り有るだろ? コメントでカバーできないような関数にはするなっていうこと?
47 : >>46 読まないといけないコードを減らして 読まなくても良いコードに置き換えろということ。 読まなくても良いコードの割合が増えれば それだけコードレビューの時間も減る。 コメントでカバーとかそういう発想をそもそもしていない。 コメントがなくてもコードでわかるのであれば、コメントすら不要。 コメントを書きたくなる時点で、コードがリーダブルでないという証拠でしかない。
48 : つまりは なでしこで書かれたプログラムが 一番リーダブルなんじゃね?
49 : 噛み合ってないスレ
50 : 関数名と言うのは、巧いコードだと処理の概要を物語るコメントとしても機能する。 例えば void BubbleSort( int *p, int n ) という関数が何をするのかは容易に推測できる。 (ただしこんな名前でクィックソートしてるなら糞コードだが。) 一方、下手なコードだと関数名は単なる識別子としてしか機能しない。 内部で何をやっているかは関数内のコードやコメント、ドキュメントを追う必要がある。 例えば void HogeMoge() という関数が何をするのかは中身を見なければまず分からない。 と書いてみる。
51 : 他人のコードを読む難しさは、”作者が暗黙にイメージしてる図”を推論することの難しさにある。 f(x+d) - f(x) / d 作者自身は「これは微分するためだ」という暗黙のイメージがあるので簡単に理解できる。 一方、他人はコードのみから「これは微分が目的か?」と推論する必要がある。 コードを推論だけで読むには、作者と同等かそれ以上のコードを書けるだけの基礎が必要となる。 これら推論を補助するには、ホワイトボードによる図説が有効である。 イメージ図が有ると無いとではコード理解の難易度が大幅に変わる。
52 : >>51 それこそ、 >>26 が言っている関数名の付け方の問題で、 関数名を xxxを微分する() にすれば良い。微分という 概念なら共有できるのだとすれば。 問題はこのように概念化、言語化できない(し難い)アルゴリズムの 場合、関数名では解決できないケースがあること。
53 : ・・・ 問題は、アルゴリズムと呼ばれているものの中には、 このような概念化、言語化できない(し難い)ものが あり、この場合は関数名では解決できない。・・ですね。
54 : 「微分ってなに?」って奴に対してリーダブルにするにはどうすればいいかってことが問題になるな
55 : ある位置の傾き
56 : >>54 それはそれで「こういう処理を微分と呼びます」でいいんじゃないの 例え新たな用語であろうと、それに対しての厳密かつ具体的な処理が示されて「こういう処理をそう呼ぶんだな」と思えないなら プログラマとしては、数学以外の分野でもかなり困ることになるぞ
57 : >>54 それは勉強すればいいことなので微分のままでいいよ。 リーダブルというのは知識不足を補うためにあるんじゃない。 会社特有の知識とか、会社やめたら無駄になるようなものは 覚える必要はまずないから、それに関するドキュメントが必要。 でも世間一般の知識は、勉強しろの一言で終わり。 それが技術力ってものだからね。 技術者である以上、自分には技術がないのでわかりません。は恥だと思え。 俺にはわからんから高度な書き方をするな。みたいなことを言ってる奴は 技術力ねぇんだなと思えばいい。自分より技術の低いやつに合わせる必要ない。 足を引っ張ってる奴が悪い。
58 : 道具が使えるだけの奴は三流。 技術・知識も使いこなせて二流。 人も使いこなせてこそ一流。
59 : ここまでオライリーの「リーダブルコード」への言及なし。 この本のいいとこ悪いとこの話題とか、 もっと深い議論があるスレを期待した俺がバカ。
60 : >>59 お前がすればいいじゃん。 他人任せなのはやめろ。 自分から行動しろ。
61 : >>57 それでは足を引っ張られる一方だろ。 自分が楽をするためには どんな馬鹿にでも判るようなやり方を使って どんな馬鹿をも楽に使えるような環境を整えるしかない。
62 : >>61 馬鹿は切り捨てるか育てるしかない。 技術者は技術があるもののことだ。 素人を基準にしてどうする? 自分が楽をしたいんだろう? 馬鹿用のやり方で楽になるわけがないだろう。
63 : >>62 人事権があるならやってる。
64 : じゃあ、それは人事権がないのが問題ということで。
65 : リーダブル関係ねえ
66 : そうそう、リーダブルというのは プロがプロのために読みやすいコードとはという話であって、 馬鹿でもわかるコードのことではない。 関数さえ理解できない馬鹿がいるんだしな。 だからそいうヤツのことを考えるのは リーダブルとは無関係。 ”リーダブルではないが”馬鹿用に仕方なく書いている。 という状態になるだけ。
67 : 馬鹿なんて言葉が出てくる時点でどうかと思うけどね。
68 : 馬鹿は切って捨てろというのは同意したいところだが、あまり理想が高すぎると誰もついて来なくなる。 そもそも原著からして「シンプルで実践的」を掲げてるわけで。
69 : >>68 > 「シンプルで実践的」 って、馬鹿^H^Hプログラミング初心者に迎合しろって意味ではないだろ
70 : 思うにコードを読むのにごく一部の天才しか知らない・理解できないような知識を要したり、 ごく一部の馬鹿の為に特別なルールが設けられているなどの背景についての理解を要するのは どちらもリーダブルではない罠。 一般的なPGの大多数が、予備知識を一切持たずにすんなり読めるコードこそリーダブルと言うべきではなかろうか。
71 : > 思うにコードを読むのにごく一部の天才しか知らない・理解できないような知識を要したり なんでそんなのを使うと思うんだ? プログラミング言語が備えている機能を 普通に使ってるだけだぞ? えとさ、例えばプロの技術者が、自分の使っている道具を 使いこなせてないとしたらどう思うよ?
72 : > 予備知識を一切持たずにすんなり読めるコード そんなものはない。 技術職なんだから技術がない人間が 読めるわけ無いだろ。 反対に言えば、技術職なんだから 素人が出来ないことをできるようになれよ。
73 : 「PGの大多数が」を省いて我田引水おいしいです
74 : お前が言うPGの大多数って馬鹿のことだろう? 具体的に言えば、入社一年未満レベル。 違うのか? 本物のプログラマが普通に読めるレベルなら プログラミング言語の機能はどれを使っても 読めるはずだが。
75 : >71-72 最後に「一般的なPGの大多数が」と書いてるのに、何故そんな解釈するのさ。 言語が備えている機能を普通に使っているコードが読めないレベルが一般的で大多数だとでも? だとしたら他を見下しすぎ。 あと「予備知識を持たずに」とは書いたけど、「勉強せずに」とは書いてないからね? 例えば余程難解な代物でも無い限り(この条件を見落とさな用に!)、コメントに「〜参照」とでも書いておくだけでも 予備知識を持たずに読めるコードになるでしょ。
76 : >74 >本物のプログラマが普通に読めるレベルなら >プログラミング言語の機能はどれを使っても >読めるはずだが。 アセンブラでフルスクラッチできるレベルなんでしょうなぁ。 トグルスィッチでミスせず入力しきった真のPGも居ますが。
77 : 一般的なPGの大多数がどの程度のものを指しているのかしらないけど、 例えば、プロジェクトがオープンソースプロジェクトで 多くの人が参加しているとしよう。 その予備知識を一切持たずにすんなり読めるコードに 書き換えましょうと提案して通るレベルならいいよ。 まあ少数の初心者のために書きなおすことはないだろうね。
78 : >>74 PGの大多数が入社一年未満レベル? なに言ってんの?
79 : ユニバーサルデザインの考え方だな。 より一般的な、説明が不要な方法で実装したほうが、 結局はみんなが幸せよ。 例えば売掛買掛とかいう概念にしがみついてんのは、 自分の立場を守ろうとする老害よ。 専門性に逃げ込むような輩は先細っていくよ。
80 : おいおい、みんな結局同じことを言ってるぞ。 リーダブルコードというのは、 初心者プログラマでも読めるレベルで書くことじゃない。 プロがプロとして読みやすいコードを書くということだ。 言語の機能には時として使わないほうがいいとされる機能もあるが、 そういうものないのなら、すべて使って良い機能だ。 言語の機能を知らないのは、初心者が頑張って技術をつけろという話であって 初心者のレベルに下げようということではない。 だろ?
81 : >>79 > より一般的な、説明が不要な方法で実装したほうが、 より一般的な、説明が不要な方法ってなんだよ? 俺らは技術者だぜ。 技術的な方法で実装するのは問題ない。 わからないのは技術が低いからなだけだろう?
82 : そもそも「初心者」っていう言葉を使ってるの一人だけっぽいが…。 我田引水っ子が混じってる気がするから気持ちよく話に参加できない。
83 : どんな技術でも使うことに正当な理由があれば使うし、 使うべきでは無いという正当な理由があれば使わないよ。 ただ「周りがわからないから使わない」は 正当な理由にはなりえないな。妥協した理由だ。
84 : >>83 なるほど。正当な理由と 妥協した理由ね。 つまりはリーダブルコードの話をする時 正当な理由のみで語るべきということ。 そこに妥協した理由を持ってきてはいけない。 妥協したいならお前の周りだけ妥協すればいいだけじゃん。 技術のなさを恥じながら妥協しておけよ。
85 : >79 >より一般的な、説明が不要な方法で実装したほうが、結局はみんなが幸せよ。 この「説明が不要」と言うのはうまい表現かもね。 専門知識・用語を駆使して「説明を省く」のとはちょっと違う。
86 : >>85 具体的に言ってよ。 専門知識・用語を使えば簡単なのに、 使わないほうがいい例を プログラミング技術の話でたとえてみて。
87 : >>81 > より一般的な、説明が不要な方法ってなんだよ? 分からないの? それは技術が低いから?
88 : >>87 いいから説明しろよ。 みんなエスパーじゃないんだからさ。 お前の考えだろ?
89 : >>88 頑張って、技術をつけてくださいね;)
90 : >>89 くだらない煽りはいらん。 さっさと寝てろ。
91 : 説明を求められて説明できない人って 何のために意見を言ったんだろうかね。
92 : >86 >専門知識・用語を使えば簡単なのに、使わないほうがいい例 例えばC++ではないC言語で、「オブジェクト」という単語が出てきたとしよう。 本当にCをよく理解しているならそれが何を意味してるのか分かると思うが、 なまじC++等を知ってるプログラマを混乱させる元になる。
93 : > 例えばC++ではないC言語で、「オブジェクト」という単語が出てきたとしよう。 その場合それは専門用語ではない。 誰かが勝手に作った用語だろう? そういう人こそちゃんと勉強して 正しい専門用語を使えと思うんだが?
94 : >>63-65 合ってるだろ、leaderぶる話で
95 : ぐんもー☆ぞうをなでなで
96 : >>88 みんなエスパーだよ?
97 : 関数型言語であるような、mapとかfilterとかは、 知らないと読めない典型だけど、いったん知ってしまえば とても便利だよね これがリーダブルなのかそうでないのかは 読み手によるとしか答えようがないなあ
98 : 技術の高さに頼らなくても読めないと駄目だろ
99 : その言語の典型的な書き方、イディオムは、読めて当然と考えていいんじゃないか? それをはずれた書き方は読むのをストップさせるリーダブルじゃないコードだろ。 イディオムを覚えていない初心者はこの議論の範疇外だよ。
100 : クラス名や関数名、主要変数名に気を使って、ぱっと見ておおまかな処理の流れさえ分かれば、細かい処理はわかりづらくてもコメント打っておけば良いと思っている 公開する範囲にもよると思うが
101 : >>97 mapやfilterはものすごく勉強しないと理解できない物? 違うよね。 ちょっと知ればいい程度のものなら、勉強すれば終わりでしょ? そんなものまで、知らないから読めないという人のために 使うかどうか迷うの? ほんの数分の勉強で、これから先ずっと快適になるんだよ。 比べるまでもないことだよね。
102 : >93 >その場合それは専門用語ではない。 >誰かが勝手に作った用語だろう? 手元にあるK&R第2版日本語訳にはこう書いてある。 【付録A(ANSI規格)】 A5 オブジェクトと左辺値 オブジェクトは名前付きのメモリ領域であり、左辺値(lvalue)はオブジェクトを参照する式である。
103 : K&Rをバイブルとする技術者には御馴染み>そのオブジェクト >>93 は頑張って勉強しなきゃな。
104 : K&Rは、もはや参考書でしかないよ。 まずは規格票を読まなきゃ。
105 : >104 「付録A」はその規格について述べてる訳ですが?
106 : 解説であって規格票そのものではないし、しかもC99じゃなくてC89のだし。
107 : 俺らの世代以上の人なら、K&Rの例の「オブジェクト」について、 少なくとも何度か話題に上がったことは当たり前にあるだろうね。
108 : >106 まともなプログラマなら>102の内容はc99でも通用する記述だと分かるだろ
109 : そもそもコードは「キーワードと文法しか知らない」コンパイラに分かるように頭から読んでいけば分かるように書いてある訳で、 どんな糞コードであっても、コンパイルが通るなら言語規格を熟知してる奴には読めるはずである。 すなわち「規格を熟知している奴に読めれば良い」という条件では糞コードを除外できない。
110 : >>103 K&Rが勝手に作った用語。
111 : CはそもそもK&RのRのほうが勝手に作った言語だけどなw
112 : 実に見事なニワカホイホイだった
113 : 小学生の口喧嘩みたいだ。
114 : 結局規格票で確認した奴はいなかった、というオチだろ?
115 : 純粋なgetter,setterじゃないのにget〜とかset〜とかは使わない方がいい? 例えば,なんかのファイルのパスを返すような関数があったとして, getHogePath()とかいう関数名はあり? もちろんhogeっていうメンバ変数はないとして
116 : >>115 Javaの話として解釈する ぱっと見て意味はわかるし良いと思う 所属しているクラス名がHogeなら、考え直した方がいいかも
117 : 動的型付け言語の場合。 クラスがHogeであっても、getHogeってした方がいいよ。 なぜなら、getだけじゃ何からのgetか分からないから。 近くでnewしていれば簡単だが、関数の外から 渡されてきたらあちこちのコードを読まないとわからない。 しかも一つ見つけたら、それで正しいとは限らない。 もしかしたら見つけたのとは別のクラスも渡しているかもしれない。
118 : 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
119 : 「リーダブルコード」的には、getHogeはオススメされていない。 ・属性値を得るだけの軽い処理とまぎらわしい ・明確じゃない(ほかの動詞を使うべき)
120 : 内部処理を意識させないために getでいいのでは? 内部処理がどうなっているか不明なのだから 軽いかどうかなんてわかり用がないし 変わることだってだろう? そこに何かの想定をしてはいけないだけの話。
121 : >>120 が英語が出来ないだけの話 リーダブルコードの意味をもう一度考えたほうがいい
122 : Foo.getHoge(); と書くと「FooがHogeをgetする」になってしまう罠。 仮にこれを「FooからHogeをgetする」と読むのならば、 if( Foo.isHoge() ) を 「もしFooがHogeなら」と読めなくなる。
123 : そのロジックはこじつけすぎ 慣習には従うべき
124 : 間違えてUCCで書いてもうた…orz でもまぁ標準ライブラリでもよく考えるとおかしなのがあるから、あまり気にせずとも良い気も。
125 : >>115 定数オーダーの処理ならget,setって言っていいイメージでいます。
126 : 話が逸れるけど関数名だけに拘るのではなく、戻り値や引数の型その他を含むシグネチャ全体に気を使った方が良いかと。 特にC/C++なんかだとconstの有無はネーミングと同じ位気を使って欲しい。 うまく使えば読みやすくなるし。
127 : そのHogePathの出どころによるよね DBから探してくるならfindHogePathとかsearchForHogePath コンポーネントをいくつか組み合わせて作るならcomposeHogePath どこかに設定してあるのをちゃちゃっと取ってくるだけならgetHogePath 処理の中身がわかる名前がいいと思うよ
128 : >>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がたまたまそう読めるからといって、だからなに? 他は違う読み方をすればいいだけじゃない。 ってことだな。
129 : >>128 RubyではFoo.newなんだが(;^ω^)
130 : >>129 だから>>122 はおかしいってことでしょ
131 : >>129 それは一文字でも短くタイプするとかいう変な宗教だろう リーダブルとは真逆
132 : Foo.new と new Foo の違いは、前者がメタオブジェクト(Classのインスタンス)の インスタンスメソッドの呼び出しであるのに対し、後者がnewという前置演算子による 演算子式である、という意味の違いが構文の違いになっているに過ぎず、 リーダビリティとは全く何の関係もない。 それを「一文字でも短くタイプするとかいう変な宗教」とか考える奴の脳味噌が変。
133 : 言いたい事をほぼ>>132 が言ってくれたから話が早いw
134 : >>131 一文字でも短くタイプするとかいう変な宗教とは、 Foo() と書くリーダブブルとは真逆な某言語のことだろw
135 : >>134 俺 Python スレとシャワートイレ板で有名コテやってるかあんまり怒らせないほうがいいよ
136 : >>134 これ一番分かりやすいな
137 : その言語において、コンストラクタが普通の関数と同じものなら、それで問題ない。 プログラミング言語は、計算のための意味論を持った、形式言語である、という前提を外した 議論からは、何も生まれないよ。
138 : >>134 Perlは Foo だけでいけるよ。
139 : >>134 なんでリーダブルとは間逆なの? 極端に短く書いたらリーダブルじゃなくなるけど、 適度に短いのはリーダブルだよね?
140 : >>134 みたいな馬鹿に賛同する奴は 本当に馬鹿なんだろうなって 心の底から思うよ。
141 : というより、ちょっと前から一人おかしい子が紛れ込んでる希ガスw 知ったようなことを言いたいんだ、ということだけ分かる。
142 : こんな感じで分かり易いコード書けるよー、的な話題になると、 気の利いたコード書けない低脳が、そんなの関数化するから関係無いと言い出し、 その結果、関数名とか変数名とか、あとメソッド呼び出しでの括弧省略とか、 そういう下らない議論になる 読んでないけど、このスレもそんな感じですか?
143 : あぁ、お前が読んでないことが2行目でわかったよw さっさと自分のスレに帰って、 そいつに泣かされてこい。
144 : 自分のスレとか言い出したら 病気ですよ
145 : >>144 ?
146 : あ、馬鹿にしたことに気づいてないのかw
147 : 自分のスレって何だ?
148 : 三人称単数ならgetsだろ藁() 小学生かお前ら核爆()
149 : >148 メンバからの呼び出しの場合
150 : >>139 new Foo や Foo.new は「適度に短い」からリーダブルだよ なぜなら、new というキーワードによって、単なるメソッド呼び出しと コンストラクタ呼び出しを一目で見分けられる、 つまりコードリーディングを配慮した言語設計だと言える それに対して、Foo() は「極端に短い」からアンリーダブルだね なぜなら、前後の文脈を確認しなければ、それがメソッド呼び出しなのか コンストラクタ呼び出しなのかが区別できない つまりコードリーディングを無視した 「一文字でも短くタイプするとかいう変な宗教(>>131 )」に従った言語設計だと言える たとえば、f() というコードは一見するとメソッド(または関数)呼び出しに見える しかし、その前の文脈に f = Foo があれば、f() の意味はコンストラクタ呼び出しになる もしも、これが new f または f.new であれば迷うこと無くコンストラクタであると判断できる
151 : > それに対して、Foo() は「極端に短い」からアンリーダブルだね なんで? Foo()という関数は読みづらいか?
152 : ていうか、何でコンストラクタと普通の関数を区別する必要があるの? 馬鹿なの?
153 : メソッドとかコンストラクタと言ってる時点で わかってないやつじゃないか。 このスレで言う、リーダブルとは 技術の低いやつに合わせることではないって 話と同じことだな。
154 : newFoo = Fooって書けばよくね???
155 : アホがアホのフリをする必要は無いぞ。
156 : そもそもオブジェクト指向とかゴミだろ藁() OCaml最高!!
157 : Objective Caml ........
158 : 第一級のモジュールができて 完全にオワコンになったOCamlのO
159 : 一時のブームに流されたばかりに.....
160 : おまえら、ここは言語の勝負するスレじゃないぞ
161 : if !flag vs. unless flag 派のたたかいはまだですか
162 : 論理的にはどちらか一方あればいいけど、 読むことを考えれば、両方できる方がいい。
163 : のってやろう 俺は!を見逃すという凡ミスでハマったゴミクソ野郎なので unless派だ
164 : 実装は同じになるけど、英語の意味は違うよ だから両方ある方がいい
165 : if not でいいじゃん
166 : 条件式は明示的に比較演算子を記述すること
167 : 俺みたいな雑魚が until と unless を間違えるから、どちらかを別の単語にすべきだ。
168 : if修飾子が好き。 条件の文字をxで置き換えて書くと next if xxxxxx next if xxxxxxxxxxxx next if xxx と揃っていて美しい。一瞬でこの一群の目的が分かる。 旧来の方法だと、 if (xxxxxx) next if (xxxxxxxxxxxx) next if (xxx) next こうなって、この一群が同一の目的を持ってることがスグには分からない。
169 : >>168 すみません。このnextっていうのは何のことですか?
170 : >>163 そう言うやつはそのうち unless !flag と書いてはまるので、俺は unless いらない派
171 : >>169 C で言うところの continue じゃね? perl とかが next だったような気がする。
172 : >>168 同じ目的ならor条件にしろ
173 : 一人だけ周回遅れな発言してるなぁ…
174 : 条件によりオプショナルなら前置 null対策などで仕方なく条件を付けるのなら後置 みたいに書いたりしないか
175 : >>168 こうすりゃいいやん if (xxxxxx) next if (xxxxxxxxxxxx) next if (xxx) next
176 : 変数宣言でそれやってるやついるな。
177 : 変なタイプミスした行をあぶりだすのに、それがいいときもある。 状況しだい。
178 : getterでretunr文の位置合わせるのはやりすぎ?
179 : そういうタイプミスをみつけやすくしたいという意味?
180 : int getSpamSpamSpam() {return spam;} int getHam() {return ham;} int getEggEggEgg() {return egg;} int getSpamSpamSpam() {return spam;} int getHam() {return ham;} int getEggEggEgg() {return egg;} 下のほうが見やすい気がするけど,同僚からは不評
181 : スペース纏められてたw
182 : int getSpamSpamSpam(){return spam;} int getHam() {return ham;} int getEggEggEgg() {return egg;} int getSpamSpamSpam() {return spam;} int getHam() {return ham;} int getEggEggEgg() {return egg;} こんな感じか?
183 : ふつうの等幅フォントのエディタで書いてコピペしてくれた方が、 navi2chでは見やすいんだが
184 : 名前と括弧の間にスペースを入れて整形するのは変かな?
185 : 変
186 : 変かどうかっていうのは、オープンソース、 それも有名で多くの人が参加しているようなものの コードをみればいいだけ。 こういうのは考えるのではなく、調べて答えを見つけようぜ。
187 :2013/10/26 変 イテレータならものによっては改行とスペース入れてそろえる
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
OpenGLスレ Part20 (122)
Java Web Application Framework総合 ver2 (101)
【初心者歓迎】C/C++室 Ver.87【環境依存OK】 (371)
静的型付け言語の潜在開発生産性は今の100倍 ×3 (561)
【上流社会】MSDNサブスクリプション総合【最先端】 (652)
ふらっとVisual C#,C♯,C#(初心者用) Part107 (667)
--log9.info------------------
【木木企画】COS-MIX【無法地帯】 (911)
神威MaRiA (721)
ぴゅあはーと (209)
【オフ会】ビッケ棒を折るスレ 4本目【虐殺】 (919)
【露出系】一騎当千のコスプレ【いっぱい】 (293)
【男装彼氏】rentalTrip cerise【開店中】 (103)
秋葉原@ほぉ〜むcafe【華】を語るスレその6 (890)
ラブライブ! μ's 93nd LoveLive! (950)
アイドルマスター(ゲーム版)の声優を語ろう 98週目 (304)
↑と↓のスレタイを合体させよう in 声優総合板 12 (109)
2013年ブレイクしそうな声優part119 (608)
AV女優に転向してほしい声優Part14 (130)
声優業界の将来について真剣に議論するスレpart2 (940)
声優雑誌について語るスレ 8冊目 (609)
【京アニ】Free!の声優を語るスレ5 (264)
[UD→BOINC]君にもできる分散処理@voice Chapter:18 (103)
--log55.com------------------
日本のナイフ好き嫌い思想
鉈 ナタ 山刀 12本目
刀剣購入 優良店 極悪店 オク 15
ダ マ シ タ
包丁総合スレ35
◆◆ガーバー GEBER 総合スレ5◆◆
【S35VN】Spyderco スパイダルコ 22【M4】
■●初心者歓迎、刃物質問&相談スレ 28