07/10/09 21:48:45
>>910
＞ガラクタを無秩序に押入れに押し込むことを抽象化と呼ぶのなら
そんなトンデモな前提に立った議論ではない。
君とか904は、まあダメなプログラマにありがちだけど
暗黙のうちに「プログラムを書いている時点の視点」に立っている。
確かにプログラムを書いている時点に限定すれば、ほとんどの場合は
関数に括り出した方が読みやすいし、見た目にもスッキリする。
「caseの中につらつら書いた」コードなんて醜いし見難いように思われる。
ところが同じコードを一年後に読むと評価が逆転するんだなこれが。
912:仕様書無しさん
07/10/09 21:53:11
なにそれ、全然理由になってない
913:仕様書無しさん
07/10/09 21:54:05
>>910
>関数名に連番とか振ってないだろうなｗ？
関数名、変数名がすべて [A-Z]{2,3}[0-9]{5} なコードの保守ならやらされたことがある。
それはともかく、case 文の中身が10行超えたら、普通 state か command か chain of responsibility あたりを使わね？
914:仕様書無しさん
07/10/09 21:54:51
case 1:
{
} break;
case 2
{
って最初に作っておいたらスコープ付くしbreak強制になるから便利
915:仕様書無しさん
07/10/09 21:55:11
>>911
オブジェクト指向にOCPってあるんだけど、きいたことある？
いろいろ勉強して、実践して、その上でいってるのか心配になっちゃうんだけど
916:仕様書無しさん
07/10/09 21:58:03
デリゲートを条件に使われる定数をインデックスにして連想配列にぶちこむのは一種のストラテジーパターンらしい
917:仕様書無しさん
07/10/09 21:59:40
>>915
そいつのレスはムダに長いが、主張したいことは最後の1-2行だけ。
そこ見たらこれ以上そいつにかまう必要が無いことがわかる。
918:仕様書無しさん
07/10/09 22:11:46
>>899
> >>898
> 一箇所からしか呼ばれないコードを関数に括りだすことが本当に可読性に資するのか。
Testability
919:仕様書無しさん
07/10/09 22:22:07
>918
君の一言を待っていた
920:仕様書無しさん
07/10/09 23:55:45
( ﾟдﾟ )
921:仕様書無しさん
07/10/10 00:47:25
この類の話は
センスがない人にはいくら説明しても理解できないんだよね。
たぶん>>899,907,911は文系か元コボラ。
922:仕様書無しさん
07/10/10 01:30:46
>>921
今追いついたけど同意
923:仕様書無しさん
07/10/10 01:38:13
厳しいこといえば、センスとか言ってるやつもヤバイ
基本中の基本だ
924:仕様書無しさん
07/10/10 01:57:12
こういうやつらが消火の悪いスパゲティ作るんだろうな
925:仕様書無しさん
07/10/10 03:54:45
燃え盛ったときに消しにくいんだな
926:仕様書無しさん
07/10/10 04:32:11
負け組PGの揚げ足取り乙
927:仕様書無しさん
07/10/10 08:17:56
>>899
逆でしょw
武道みたいにプログラミングでもスタイルや「型」は大事だし、
それらはほとんどの場合正しいが、いつでも正しいわけじゃない。
意味を持った処理は関数に括り出して抽象化することによって読みやすくなる、
という「型」はほとんどの場合正しいが、いつでも正しいわけじゃないんだが、
自分の頭で考えられない教条主義者（＝「センス」を欠いた人間）にはそれが
判断できないし、そういう発想が頭をよぎっても抑圧してしまうんだね。
王様は裸だ、と言えないのと同じ心理的メカニズムが作用するからねw
928:仕様書無しさん
07/10/10 08:38:05
何が「逆」なのか、説明してくれ
929:仕様書無しさん
07/10/10 10:11:44
おまえら、当然ファウラーの「リファクタリング」を読んだ上で発言しているだろうな。
930:仕様書無しさん
07/10/10 11:43:05
>>929
教科書主義者乙
931:仕様書無しさん
07/10/10 12:09:26
> 教科書主義
932:仕様書無しさん
07/10/10 12:15:19
いくら教条主義はNGだからつって、そもそも教科書読んでねえやつは論外なわけだ
933:仕様書無しさん
07/10/10 15:16:54
同意
934:仕様書無しさん
07/10/10 21:36:24
>>927
あいかわらずムダな長文だな。自分にレスして楽しいか？
935:仕様書無しさん
07/10/10 23:40:23
俺には無意味な事を二度書いて、
最後に無関係なたとえ話をしている様に見える。
誰か >>927 をリファクタリングしてくれ。
936:仕様書無しさん
07/10/10 23:49:49
case毎の処理を関数に切り出すと読み辛くなるってのは、
caseの切り分け方がおかしい証拠に他ならんと思うのだが。
あと
>927
>意味を持った処理は関数に括り出して抽象化することによって読みやすくなる、
>という「型」はほとんどの場合正しいが、いつでも正しいわけじゃないんだが
の「正しくないケース」ってどんな時さ。
抽象化によって読み辛くなるのは、抽象化の仕方がおかしい時だけでしょ。
937:仕様書無しさん
07/10/10 23:50:25
>>935
#修正しておきました。
938:仕様書無しさん
07/10/11 00:07:05
>>937
全消しかいｗ
939:仕様書無しさん
07/10/11 00:39:54
>>936
>>898-を参照
940:仕様書無しさん
07/10/11 00:45:20
WTLのメッセージマップとか激しく便利だお
941:仕様書無しさん
07/10/11 19:34:57
>>936
正しくないケースを考えてみた。
1. >>927みたいな奴しかいない現場
2. 作成した関数を全て紙で管理している現場
3. 将来メンテする奴への嫌がらせ
4. リソースがカツカツ
5. そもそもサブロジックを切り出せない言語だ
6. コンパイラの限界に挑戦中
こんなもんか？
942:936
07/10/12 02:21:01
>941
納得してしまった。w
943:仕様書無しさん
07/10/12 09:24:34
>>941
>5. そもそもサブロジックを切り出せない言語だ
そうかN88-BASICだったんだ
944:仕様書無しさん
07/10/12 11:56:55
N88-BASICじゃ仕方ないなｗ
N88-BASICでも、変数名と戻り値代わりに使う変数名を工夫すれば
GOSUB との組み合わせで何とかなるかもしれんが
本質じゃない不毛なコードが大量生産されそうだ
945:仕様書無しさん
07/10/12 13:33:21
いろんな火災現場を転々としてるダメPGが言うのもなんだけど
どちらの書き方でも、どんなに拘りの秘伝のソースでもいいが
可読性の無いソースを書くのはやめて欲しい。。
>>944
BASICの頃でも、ON (式) GOSUB *Label...でサブルーチン化はしてたよ。
946:仕様書無しさん
07/10/12 13:59:28
>945
>可読性の無いソースを書くのはやめて欲しい。。
無理。
自分の常識は他人の非常識である場合が多い。
# だからflgで３値を返すなとあれほど･･･
947:仕様書無しさん
07/10/13 15:07:00
いやそもそも可読性が無ければ保守不能だし。「可読性が低い」だろ。
じゃあその可読性の水準を向上させるためにはどうすれば良いか。
という話になるけど。これは99%以上が独学だろ。
スレの上のほうに出てきた本を読んでおくのは当然。
OSSという容易に読めるコードもあるじゃないか。