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

**デフォルトの名無しさん** · 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
>コードを毎回のように読まなくてはいけないものと
>コードを（初回レビュー以外）読まなくても大丈夫なもの
>二通り有るだろ？
コメントでカバーできないような関数にはするなっていうこと？

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

>>46
読まないといけないコードを減らして
読まなくても良いコードに置き換えろということ。

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

コメントでカバーとかそういう発想をそもそもしていない。
コメントがなくてもコードでわかるのであれば、コメントすら不要。
コメントを書きたくなる時点で、コードがリーダブルでないという証拠でしかない。

**デフォルトの名無しさん** · 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() という関数が何をするのかは中身を見なければまず分からない。

と書いてみる。

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

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

これら推論を補助するには、ホワイトボードによる図説が有効である。
イメージ図が有ると無いとではコード理解の難易度が大幅に変わる。

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

>>51
それこそ、 >>26 が言っている関数名の付け方の問題で、
関数名を xxxを微分する() にすれば良い。微分という
概念なら共有できるのだとすれば。
問題はこのように概念化、言語化できない(し難い)アルゴリズムの
場合、関数名では解決できないケースがあること。

52 · 2013/10/16(水) 07:00:14.97

・・・
問題は、アルゴリズムと呼ばれているものの中には、
このような概念化、言語化できない(し難い)ものが
あり、この場合は関数名では解決できない。・・ですね。

**デフォルトの名無しさん** · 2013/10/16(水) 07:02:42.74

「微分ってなに？」って奴に対してリーダブルにするにはどうすればいいかってことが問題になるな

**デフォルトの名無しさん** · 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

リーダブル関係ねえ

**デフォルトの名無しさん** · 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プログラミング初心者に迎合しろって意味ではないだろ

68 · 2013/10/21(月) 23:27:32.33

思うにコードを読むのにごく一部の天才しか知らない・理解できないような知識を要したり、
ごく一部の馬鹿の為に特別なルールが設けられているなどの背景についての理解を要するのは
どちらもリーダブルではない罠。

一般的なPGの大多数が、予備知識を一切持たずにすんなり読めるコードこそリーダブルと言うべきではなかろうか。

**デフォルトの名無しさん** · 2013/10/22(火) 00:26:07.90

> 思うにコードを読むのにごく一部の天才しか知らない・理解できないような知識を要したり

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

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

えとさ、例えばプロの技術者が、自分の使っている道具を
使いこなせてないとしたらどう思うよ？

**デフォルトの名無しさん** · 2013/10/22(火) 00:27:18.97

> 予備知識を一切持たずにすんなり読めるコード
そんなものはない。

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

反対に言えば、技術職なんだから
素人が出来ないことをできるようになれよ。

**デフォルトの名無しさん** · 2013/10/22(火) 00:35:47.94

「PGの大多数が」を省いて我田引水おいしいです

**デフォルトの名無しさん** · 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も居ますが。

**デフォルトの名無しさん** · 2013/10/22(火) 00:54:37.35

一般的なPGの大多数がどの程度のものを指しているのかしらないけど、
例えば、プロジェクトがオープンソースプロジェクトで
多くの人が参加しているとしよう。

その予備知識を一切持たずにすんなり読めるコードに
書き換えましょうと提案して通るレベルならいいよ。
まあ少数の初心者のために書きなおすことはないだろうね。

**デフォルトの名無しさん** · 2013/10/22(火) 00:56:14.61

>>74
PGの大多数が入社一年未満レベル？
なに言ってんの？

**デフォルトの名無しさん** · 2013/10/22(火) 00:58:27.98

ユニバーサルデザインの考え方だな。
より一般的な、説明が不要な方法で実装したほうが、
結局はみんなが幸せよ。

例えば売掛買掛とかいう概念にしがみついてんのは、
自分の立場を守ろうとする老害よ。
専門性に逃げ込むような輩は先細っていくよ。

**デフォルトの名無しさん** · 2013/10/22(火) 01:01:20.34

おいおい、みんな結局同じことを言ってるぞ。

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

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

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

だろ？

**デフォルトの名無しさん** · 2013/10/22(火) 01:02:49.59

>>79
> より一般的な、説明が不要な方法で実装したほうが、

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

技術的な方法で実装するのは問題ない。
わからないのは技術が低いからなだけだろう？

**デフォルトの名無しさん** · 2013/10/22(火) 01:04:44.66

そもそも「初心者」っていう言葉を使ってるの一人だけっぽいが…。
我田引水っ子が混じってる気がするから気持ちよく話に参加できない。

**デフォルトの名無しさん** · 2013/10/22(火) 01:05:25.45

どんな技術でも使うことに正当な理由があれば使うし、
使うべきでは無いという正当な理由があれば使わないよ。

ただ「周りがわからないから使わない」は
正当な理由にはなりえないな。妥協した理由だ。

**デフォルトの名無しさん** · 2013/10/22(火) 01:08:07.19

>>83
なるほど。正当な理由と
妥協した理由ね。

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

そこに妥協した理由を持ってきてはいけない。
妥協したいならお前の周りだけ妥協すればいいだけじゃん。
技術のなさを恥じながら妥協しておけよ。

**デフォルトの名無しさん** · 2013/10/22(火) 01:09:50.20

>79
>より一般的な、説明が不要な方法で実装したほうが、結局はみんなが幸せよ。

この「説明が不要」と言うのはうまい表現かもね。
専門知識・用語を駆使して「説明を省く」のとはちょっと違う。

**デフォルトの名無しさん** · 2013/10/22(火) 01:14:31.11

>>85
具体的に言ってよ。

専門知識・用語を使えば簡単なのに、
使わないほうがいい例を
プログラミング技術の話でたとえてみて。

**デフォルトの名無しさん** · 2013/10/22(火) 01:16:15.84

>>81
> より一般的な、説明が不要な方法ってなんだよ？

分からないの？
それは技術が低いから？

**デフォルトの名無しさん** · 2013/10/22(火) 01:17:05.09

>>87
いいから説明しろよ。

みんなエスパーじゃないんだからさ。
お前の考えだろ？

**デフォルトの名無しさん** · 2013/10/22(火) 01:17:50.73

>>88
頑張って、技術をつけてくださいね;)

**デフォルトの名無しさん** · 2013/10/22(火) 01:18:19.54

>>89
くだらない煽りはいらん。
さっさと寝てろ。

**デフォルトの名無しさん** · 2013/10/22(火) 01:18:59.89

説明を求められて説明できない人って
何のために意見を言ったんだろうかね。

**デフォルトの名無しさん** · 2013/10/22(火) 01:25:54.50

>86
>専門知識・用語を使えば簡単なのに、使わないほうがいい例

例えばC++ではないC言語で、「オブジェクト」という単語が出てきたとしよう。
本当にCをよく理解しているならそれが何を意味してるのか分かると思うが、
なまじC++等を知ってるプログラマを混乱させる元になる。

**デフォルトの名無しさん** · 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

ぐんもー☆ぞうをなでなで

**デフォルトの名無しさん** · 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

クラス名や関数名、主要変数名に気を使って、ぱっと見ておおまかな処理の流れさえ分かれば、細かい処理はわかりづらくてもコメント打っておけば良いと思っている

公開する範囲にもよると思うが

**デフォルトの名無しさん** · 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なら、考え直した方がいいかも

**デフォルトの名無しさん** · 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はオススメされていない。
・属性値を得るだけの軽い処理とまぎらわしい
・明確じゃない（ほかの動詞を使うべき）

**デフォルトの名無しさん** · 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

そのロジックはこじつけすぎ
慣習には従うべき

**122** · 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

自分のスレって何だ？

**デフォルトの名無しさん** · 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

アホがアホのフリをする必要は無いぞ。

**デフォルトの名無しさん** · 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っていうのは何のことですか？

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

>>163
そう言うやつはそのうち unless !flag と書いてはまるので、俺は unless いらない派

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

>>169
C で言うところの continue じゃね？
perl とかが next だったような気がする。

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

>>168
同じ目的ならor条件にしろ

**デフォルトの名無しさん** · 2013/10/25(金) 12:31:03.71

一人だけ周回遅れな発言してるなぁ…

**デフォルトの名無しさん** · 2013/10/25(金) 20:13:24.30

条件によりオプショナルなら前置
null対策などで仕方なく条件を付けるのなら後置

みたいに書いたりしないか

**デフォルトの名無しさん** · 2013/10/25(金) 23:00:46.24

>>168
こうすりゃいいやん

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

**デフォルトの名無しさん** · 2013/10/25(金) 23:24:53.78

変数宣言でそれやってるやついるな。

**デフォルトの名無しさん** · 2013/10/26(土) 00:49:23.99

変なタイプミスした行をあぶりだすのに、それがいいときもある。
状況しだい。

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

getterでretunr文の位置合わせるのはやりすぎ？

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

そういうタイプミスをみつけやすくしたいという意味？

**デフォルトの名無しさん** · 2013/10/26(土) 16:11:57.24

int getSpamSpamSpam() {return spam;}
int getHam() {return ham;}
int getEggEggEgg() {return egg;}

int getSpamSpamSpam() {return spam;}
int getHam() {return ham;}
int getEggEggEgg() {return egg;}

下のほうが見やすい気がするけど，同僚からは不評

**デフォルトの名無しさん** · 2013/10/26(土) 16:15:01.79

スペース纏められてたw

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

int getSpamSpamSpam(){return spam;}
int getHam() {return ham;}
int getEggEggEgg() {return egg;}

int getSpamSpamSpam() {return spam;}
int getHam()　　　　　　　　{return ham;}
int getEggEggEgg() 　　　　{return egg;}

こんな感じか？

**デフォルトの名無しさん** · 2013/10/26(土) 16:25:30.69

ふつうの等幅フォントのエディタで書いてコピペしてくれた方が、
navi2chでは見やすいんだが

**デフォルトの名無しさん** · 2013/10/26(土) 21:25:49.66

名前と括弧の間にスペースを入れて整形するのは変かな？

**デフォルトの名無しさん** · 2013/10/26(土) 22:35:48.73

変

**デフォルトの名無しさん** · 2013/10/26(土) 23:00:18.20

変かどうかっていうのは、オープンソース、
それも有名で多くの人が参加しているようなものの
コードをみればいいだけ。

こういうのは考えるのではなく、調べて答えを見つけようぜ。

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

変
イテレータならものによっては改行とスペース入れてそろえる

**デフォルトの名無しさん** · 2013/12/03(火) 11:00:09.00

>>182
もっと名前の長い関数を追加することになったら面倒だろ

**デフォルトの名無しさん** · 2013/12/04(水) 01:09:35.65

関数の中身を見比べる必要がある時点でおかしいだろと思った

**デフォルトの名無しさん** · 2013/12/05(木) 07:45:11.65

達人プログラマでも同じようなインデントしてたし
>>182はそこまで変ではないのでは？

**デフォルトの名無しさん** · 2013/12/06(金) 01:25:03.50

見た目云々より、エディタの矩形選択とかを活かせるメリットの方が大きい気が。

**デフォルトの名無しさん** · 2013/12/29(日) 23:04:49.03

クラスの中のある関数をつかうために
あらかじめいくつかの要素をsetしておかないといけないという設計はよくない？
setしないで関数を呼び出したときには例外を出す感じ

コンストラクタにいれてしまったほうがいいんだろうか？

**デフォルトの名無しさん** · 2013/12/29(日) 23:06:02.09

>>192
うん。
何か気に入らないの？

**デフォルトの名無しさん** · 2013/12/29(日) 23:59:47.76

>>193
コンストラクタの引数に不正な値をいれたときの処理が気になる
コンストラクタの中で例外だすのってありだっけ？
そうするとインスタンス生成してから使うところをtryで囲まないといけないし

**デフォルトの名無しさん** · 2013/12/30(月) 00:03:01.47

>>194
ありだよ。

「tryで囲まないといけない」ってのも疑わしいが、それがほんとだとしても
「setしないで関数を呼び出したときには例外を出す」ってしたときと何が違うんだ？

**デフォルトの名無しさん** · 2013/12/30(月) 00:20:47.15

try {
____a = A()
____a.set(something)
____a.do_something()
}
か
a = A()
try {
____a.set(something)
}
a.do_something()
の違いだと思ってる
コンストラクタで例外がでるとそのクラスのインスタンスを使うところ
すべてtryで囲まないといけなくない？

**デフォルトの名無しさん** · 2013/12/30(月) 00:21:24.74

a = Noen
try{
____a = A()
}
a.do_something()
にしろってこと？

**デフォルトの名無しさん** · 2013/12/30(月) 01:20:49.83

>>196-197
それでいいんじゃね？

ごく狭い範囲をtryで囲むみたいなレアケースの見た目（いずれにしても残念）を
なんでそんなに気にしてるのか知らんけど。

**デフォルトの名無しさん** · 2013/12/30(月) 02:04:19.44

FactoryMethodパターンもいいかも。

これだったら、値を解析して正しい値だったらクラスを生成して返し、
不正だったらnullか、ヌルオブジェクトパターンでダミーのオブジェクトを返してやるとか色々出来るから。

A create(int youso)
{
if(yousoが正常) return new A(youso);
else return null;
}

class A
{
int _a;
A(int youso) { _a = youso; }
}

**デフォルトの名無しさん** · 2013/12/30(月) 09:03:57.73

>>198
コンストラクタに例外がある場合の書き方がよくわからなかった

>>199
こういう方法もあるのか
参考になります