1 仕様書無しさん :2007/02/04(日) 20:12:15
美しいプログラムってどんなの？
2 仕様書無しさん :2007/02/04(日) 20:40:46簡潔かつ可読性が高く、それでいて要件を満たす様が
見るものに感動を与えるプログラム。
3 仕様書無しさん :2007/02/04(日) 20:41:55見るものに感動を与えるプログラム。
「いい仕事してますね〜」なプログラム
5 先生 :2007/02/04(日) 23:29:30
よし、俺が美しいプログラムがどんなものかレクチャーしてやるよ。
と、その前に汚いプログラムとはどんなものかを理解する必要がある。敵を
知らば百選なんとかとやらだ。
オブジェクト指向といえど、個々の処理をメソッド単位でみると、順処理
と分岐の羅列にすぎない。あとループとかあるがここではおいとく。
で、例えば、Ａという処理をするのに、分岐が３箇所必要だとする。
if(i == 0) { ←(1)
....
} else if(i == 1){ ←(2)
...
} else { ←(3)
...
}
同じくＢという処理をするのに、分岐が４箇所必要だとする。
そして、これらの処理が関連したものだとすると、お前らは、これら一連
の処理を無邪気にもだらだらと同じメソッドfuncAB()内に書いてしまうん
だな。
6 先生 :2007/02/04(日) 23:30:55と、その前に汚いプログラムとはどんなものかを理解する必要がある。敵を
知らば百選なんとかとやらだ。
オブジェクト指向といえど、個々の処理をメソッド単位でみると、順処理
と分岐の羅列にすぎない。あとループとかあるがここではおいとく。
で、例えば、Ａという処理をするのに、分岐が３箇所必要だとする。
if(i == 0) { ←(1)
....
} else if(i == 1){ ←(2)
...
} else { ←(3)
...
}
同じくＢという処理をするのに、分岐が４箇所必要だとする。
そして、これらの処理が関連したものだとすると、お前らは、これら一連
の処理を無邪気にもだらだらと同じメソッドfuncAB()内に書いてしまうん
だな。
だけど、危機察知能力に優れた俺はそんなことはしない。
funcA()とfuncB()にそれぞれ分ける。そして、funcAB()からfuncA()とfuncB()
を呼ぶようにする。
なぜそうするかという理由は幾つかあるが、ひとつにはテストのしやすさ
がある。
funcA()とfuncB()に分けた場合、funcA()をテストするのにテストケースを
３種類。funcB()をテストするのにテストケースを４種類用意すればいいん
だが、funcAB()にごっちゃにした場合、最悪１２種類（３×４）のテストケー
スを用意しなければならない。これは恐らく本来の要件でないケースが多い。
メソッドの粒度を細かくして、個々のテストを確実にした上で結合させた方
が理解のし易さ、効率、保守性等に優れるのは明らかだ。
7 先生 :2007/02/04(日) 23:32:07funcA()とfuncB()にそれぞれ分ける。そして、funcAB()からfuncA()とfuncB()
を呼ぶようにする。
なぜそうするかという理由は幾つかあるが、ひとつにはテストのしやすさ
がある。
funcA()とfuncB()に分けた場合、funcA()をテストするのにテストケースを
３種類。funcB()をテストするのにテストケースを４種類用意すればいいん
だが、funcAB()にごっちゃにした場合、最悪１２種類（３×４）のテストケー
スを用意しなければならない。これは恐らく本来の要件でないケースが多い。
メソッドの粒度を細かくして、個々のテストを確実にした上で結合させた方
が理解のし易さ、効率、保守性等に優れるのは明らかだ。
もうひとつ、funcA()の処理が別の処理でも必要になったとする。関数分割
してあれば、単にそこで、funcA()を呼ぶだけだ。しかし、funcAB()にごっちゃ
にしてあったとするとそうはいかない。こういう時は無邪気なお前らはすぐ
にコードをコピペする。しかしこれはいただけない。汚いコードの典型だ。
仮にfuncA()の処理内容を変更しなければならなくなった時、お前らがキャッ
キャッキャッキャとコピペした箇所をぜ〜〜〜〜〜〜〜〜ぶっ修正してまわ
らなければならないのだ。これ最悪。善良な俺でも殺意が芽生えてくる。
気をつけるように。関数分割を面倒くさがるなよ。
今日は夜も遅いからここまで。じゃーな。復習しとけよ。
13 仕様書無しさん :2007/02/05(月) 13:29:23してあれば、単にそこで、funcA()を呼ぶだけだ。しかし、funcAB()にごっちゃ
にしてあったとするとそうはいかない。こういう時は無邪気なお前らはすぐ
にコードをコピペする。しかしこれはいただけない。汚いコードの典型だ。
仮にfuncA()の処理内容を変更しなければならなくなった時、お前らがキャッ
キャッキャッキャとコピペした箇所をぜ〜〜〜〜〜〜〜〜ぶっ修正してまわ
らなければならないのだ。これ最悪。善良な俺でも殺意が芽生えてくる。
気をつけるように。関数分割を面倒くさがるなよ。
今日は夜も遅いからここまで。じゃーな。復習しとけよ。
>>5-7
分岐ごとに継承クラスを作ってfactoryパターンでブン回すってのはナシですか。
15 先生 :2007/02/06(火) 00:38:36分岐ごとに継承クラスを作ってfactoryパターンでブン回すってのはナシですか。
>>13 すまん、意味がよくわらかん。その労力に見合うだけのメリットがあれば
そうすればいいと思うが。まぁデザパタについては別の機会に。
関数やメソッドを極力分割することの重要性については、昨日も述べた通りだ。
最低これだけは守って欲しい。これすらできていないソースは見られることを
恥だと思った方がいい。また、他の人にかなりの迷惑をかけることにもなる。
プログラミングというものは、便利な部品を用意して組み上げていくレゴブロッ
クのようなものだ。ところがお前らときたら、ブロックをこねこねと粘土のよう
にこねくりまわして大きな塊にしたがる。これではダメだ。
目の前に粘土があったら、その粘土から、まずはブロックを作って欲しい。
手を作り、足を作り、顔をつくり、それらを接合して生き物を完成させるんだ。
そして、これらの部品は極力粒度を細かくした方がいい。
12 仕様書無しさん :2007/02/05(月) 03:13:54そうすればいいと思うが。まぁデザパタについては別の機会に。
関数やメソッドを極力分割することの重要性については、昨日も述べた通りだ。
最低これだけは守って欲しい。これすらできていないソースは見られることを
恥だと思った方がいい。また、他の人にかなりの迷惑をかけることにもなる。
プログラミングというものは、便利な部品を用意して組み上げていくレゴブロッ
クのようなものだ。ところがお前らときたら、ブロックをこねこねと粘土のよう
にこねくりまわして大きな塊にしたがる。これではダメだ。
目の前に粘土があったら、その粘土から、まずはブロックを作って欲しい。
手を作り、足を作り、顔をつくり、それらを接合して生き物を完成させるんだ。
そして、これらの部品は極力粒度を細かくした方がいい。
カタリーナビットとかミッシェルクワンだと言う奴もいるだろうが
おれはやっぱり真央タンだな。ショートプログラムなら今季のやつ。
14 仕様書無しさん :2007/02/05(月) 13:59:46おれはやっぱり真央タンだな。ショートプログラムなら今季のやつ。
>>12 ジャネット・リンを落とすな！
16 先生 :2007/02/06(火) 00:39:11で、今日は、関数の引数について述べてみたい。
例えば、いまfuncA()という関数を作っていて、その処理をするのに、a, b, c
3つの情報が必要だとする。(ここでの、a, b, c はintやlong等のプリミティブ
型、または、stringやdate等の基本型とする)
そして、このうち、bとc の値は D というクラスのインスタンスから取得でき
る(D.getB()、D.getC()等)とする。しかし、funcAの引数をfuncA(a, D)として
はいけない。いや絶対ダメというわけではないし、状況にもよるが、やはりこ
こは極力 funcA(a, b, c) としてほしい。
17 先生 :2007/02/06(火) 00:40:13例えば、いまfuncA()という関数を作っていて、その処理をするのに、a, b, c
3つの情報が必要だとする。(ここでの、a, b, c はintやlong等のプリミティブ
型、または、stringやdate等の基本型とする)
そして、このうち、bとc の値は D というクラスのインスタンスから取得でき
る(D.getB()、D.getC()等)とする。しかし、funcAの引数をfuncA(a, D)として
はいけない。いや絶対ダメというわけではないし、状況にもよるが、やはりこ
こは極力 funcA(a, b, c) としてほしい。
なぜ、funcA(a, D)は望ましくないのか。それは、この関数とクラスDとの結び
付きを断つためだ。funcA(a, D) としてしまうと、例えば別の処理でこの関数
を呼びたい時にも、クラスDのインスタンスが必要になってしまう。つまり、
この関数がクラスDに依存してしまうことになってしまう｡それはあまりレゴの
ブロックとしてはよろしくない。顔にしか使えないブロック（まぁそれが便利な
時もあるが）よりも、足でも手でも使えるようなブロックを用意した方がいい。
（つまり汎用化を意識しようということだ。） ・・・今日はここまで。
19 仕様書無しさん :2007/02/06(火) 01:07:46付きを断つためだ。funcA(a, D) としてしまうと、例えば別の処理でこの関数
を呼びたい時にも、クラスDのインスタンスが必要になってしまう。つまり、
この関数がクラスDに依存してしまうことになってしまう｡それはあまりレゴの
ブロックとしてはよろしくない。顔にしか使えないブロック（まぁそれが便利な
時もあるが）よりも、足でも手でも使えるようなブロックを用意した方がいい。
（つまり汎用化を意識しようということだ。） ・・・今日はここまで。
>>17
場合にもよるがそういう際は
funcAをＤ内の関数にすればいいことが多いんじゃないの。
aだけ外部の変数として、その関数を外部から使うときはD.funcA(a) などという形のものする。
そうすればそもそもb,cを引数にしなくてよくなったりする。
26 仕様書無しさん :2007/02/06(火) 13:30:58場合にもよるがそういう際は
funcAをＤ内の関数にすればいいことが多いんじゃないの。
aだけ外部の変数として、その関数を外部から使うときはD.funcA(a) などという形のものする。
そうすればそもそもb,cを引数にしなくてよくなったりする。
>>16-17
依存したくないのならインターフェースを挟めばいいじゃない。
将来funcA(a, b, c)がfuncA(a, b, c, d, e, f, g)とかになったらどーすんの。
28 先生 :2007/02/06(火) 22:38:53依存したくないのならインターフェースを挟めばいいじゃない。
将来funcA(a, b, c)がfuncA(a, b, c, d, e, f, g)とかになったらどーすんの。
>>26
>>将来funcA(a, b, c)がfuncA(a, b, c, d, e, f, g)とかになったらどーすんの。
それをいうと、funcA(a, D)でも、funcA(a, D, E, f, G...)とかになってしまう
可能性はあるわけで、その場合は、もう別物として、funcB(a, b, c, d, e, f, g)
を定義し、そのfuncBの中で、funcA(a, b, c) を利用できないかを考えてみた方がいい。
昨日も書いたように、funcA(a, D)を全面的に否定するつもりはない。メソッドの
変数が多くて見にくくなってしまうのを嫌って寧ろ積極的につかう場合もある。
d = new D();
d.setA(a);
d.setB(b);
d.setC(c);
funcA(d);
しかし、この場合は、funcA()がDクラスに依存することが前提なのだ。はじめから
そういう関数なのである。funcA自体がDのための関数なのである。>>19 が書いている
ように、この場合はもう、Dのメンバ関数にしてしまった方がいい場合が多いだろう。
18 仕様書無しさん :2007/02/06(火) 01:07:27>>将来funcA(a, b, c)がfuncA(a, b, c, d, e, f, g)とかになったらどーすんの。
それをいうと、funcA(a, D)でも、funcA(a, D, E, f, G...)とかになってしまう
可能性はあるわけで、その場合は、もう別物として、funcB(a, b, c, d, e, f, g)
を定義し、そのfuncBの中で、funcA(a, b, c) を利用できないかを考えてみた方がいい。
昨日も書いたように、funcA(a, D)を全面的に否定するつもりはない。メソッドの
変数が多くて見にくくなってしまうのを嫌って寧ろ積極的につかう場合もある。
d = new D();
d.setA(a);
d.setB(b);
d.setC(c);
funcA(d);
しかし、この場合は、funcA()がDクラスに依存することが前提なのだ。はじめから
そういう関数なのである。funcA自体がDのための関数なのである。>>19 が書いている
ように、この場合はもう、Dのメンバ関数にしてしまった方がいい場合が多いだろう。
構造化とは複雑さをブロックによって制御する方法であり
オブジェクト指向とは複雑さを多層化により制御する方法である
24 仕様書無しさん :2007/02/06(火) 11:12:53オブジェクト指向とは複雑さを多層化により制御する方法である
定義なぞ無い。
ある人が美しいと思えばそのプログラムはその人にとって美しい
だいたい定義ってなんだよ。
定義とは未定義用語の上に積み重ねられるものだろ？
「美しい」は未定義用語なのだが。
33 仕様書無しさん :2007/02/07(水) 00:10:20ある人が美しいと思えばそのプログラムはその人にとって美しい
だいたい定義ってなんだよ。
定義とは未定義用語の上に積み重ねられるものだろ？
「美しい」は未定義用語なのだが。
>>24
定義がないって意味わかんね。定義すりゃ「定義」なんじゃないの？
だいたい、「ある人が美しいと思えばそのプログラムはその人にとって美しい」
この文章自体がお前にとっての「美しさ」の定義なんじゃないの？
25 仕様書無しさん :2007/02/06(火) 11:22:29定義がないって意味わかんね。定義すりゃ「定義」なんじゃないの？
だいたい、「ある人が美しいと思えばそのプログラムはその人にとって美しい」
この文章自体がお前にとっての「美しさ」の定義なんじゃないの？
コメントが全て英語とか。
29 先生 :2007/02/06(火) 22:39:52しかし、最初の例の場合は、説明不足だったが、もう少し全般的な関数を意識して
いる。こういった関数でどうしても引数を変更する必要がでてきた場合は、グローバル
な変数やフラグを使って無理をするより、後々を考えると、もう素直にシグニチャを
変更する道を選んだ方がいい。
それでなくともコードというものは細かい無理が積み重なって、図らずも次第に汚く
なっていくものだ。
今はいろんなツールのおかげでリファクタリングも大分やり易くなった。勇気をもって
リファクタリングして欲しい。ただそのためには、いつでも簡単にテストできる環境を
作っておくことが必要だ。え？分かってるって？ すまん。
今日はこの辺で。
30 仕様書無しさん :2007/02/06(火) 22:56:32いる。こういった関数でどうしても引数を変更する必要がでてきた場合は、グローバル
な変数やフラグを使って無理をするより、後々を考えると、もう素直にシグニチャを
変更する道を選んだ方がいい。
それでなくともコードというものは細かい無理が積み重なって、図らずも次第に汚く
なっていくものだ。
今はいろんなツールのおかげでリファクタリングも大分やり易くなった。勇気をもって
リファクタリングして欲しい。ただそのためには、いつでも簡単にテストできる環境を
作っておくことが必要だ。え？分かってるって？ すまん。
今日はこの辺で。
そんだけ汎用化したいのなら、そもそも引数じゃなくてプロパティ設定したほうが早いと思うが。
31 仕様書無しさん :2007/02/06(火) 23:17:57プロパティ使っちゃうと値の受け渡しが不明瞭になっちゃわない？
32 仕様書無しさん :2007/02/06(火) 23:50:08作成者コメントの名前が女
34 仕様書無しさん :2007/02/07(水) 00:10:45仕様書が美しければ、おのずとプログラムも美しくなる。
>>32
女のコードはきたねーけどな。
35 仕様書無しさん :2007/02/07(水) 00:13:32>>32
女のコードはきたねーけどな。
>>34
よくそういうレス見るけど、そんなにプログラムに近いレベルで仕様書書かれてるのか？
36 仕様書無しさん :2007/02/07(水) 00:18:53よくそういうレス見るけど、そんなにプログラムに近いレベルで仕様書書かれてるのか？
お客様からいただいたメルヘンチックな仕様書のことじゃないよ。
37 仕様書無しさん :2007/02/07(水) 01:10:11ファンタジックといいたまえ
62 仕様書無しさん :2007/02/11(日) 06:14:39ソース読みやすいっていうのは開発者側から見ると美しい
プログラムという観点からすると処理速度とかメモリとかを気にして書いてるものが美しい
モバイル系とかだと容量削減にも気を遣いつつ処理速度も気にしてかいてあるものが美しい
という感じで各視点毎に美しいの定義は変わってくると思う
最近はマシンの性能も上がってることもあり何も考えないｽﾊﾟｹﾞｯﾃｨｰｿｰｽ書く奴が多くて将来不安だわ
63 仕様書無しさん :2007/02/11(日) 12:52:04プログラムという観点からすると処理速度とかメモリとかを気にして書いてるものが美しい
モバイル系とかだと容量削減にも気を遣いつつ処理速度も気にしてかいてあるものが美しい
という感じで各視点毎に美しいの定義は変わってくると思う
最近はマシンの性能も上がってることもあり何も考えないｽﾊﾟｹﾞｯﾃｨｰｿｰｽ書く奴が多くて将来不安だわ
>最近はマシンの性能も上がってることもあり何も考えないｽﾊﾟｹﾞｯﾃｨｰｿｰｽ書く奴が多くて将来不安だわ
×最近は
○かなり以前から
65 仕様書無しさん :2007/02/11(日) 13:15:29×最近は
○かなり以前から
ある程度万人向けとなると、自然と簡単なプログラムにならざるを得ない。
66 仕様書無しさん :2007/02/11(日) 13:27:10生産性を落としてまで万人向けに書く意味がわからない。
四則演算だけつかって使って説明すれば、小学生でも高度な数学の定理が理解できるかどうか
考えてみればわかるはず。
67 仕様書無しさん :2007/02/11(日) 13:27:23四則演算だけつかって使って説明すれば、小学生でも高度な数学の定理が理解できるかどうか
考えてみればわかるはず。
やっぱり読みやすいのが一番だろうね。
１．変数のネーミングが的確
２．関数の大きさが適量
３．ネストが深くない
88 仕様書無しさん :2007/02/12(月) 23:31:24１．変数のネーミングが的確
２．関数の大きさが適量
３．ネストが深くない
やっぱクラスとか関数同士の結合が小さいプログラムが
美しいかな。。。
100 仕様書無しさん :2007/02/13(火) 23:46:06美しいかな。。。
俺、ここに書かれてる技術的なこと殆ど理解できないんだけど、
こういう事を語れるおまえらが羨ましい
101 仕様書無しさん :2007/02/13(火) 23:52:21こういう事を語れるおまえらが羨ましい
>>100
俺らはお前と違って、プログラム書く以外に趣味持たないからな。
117 短文先生 :2007/02/15(木) 01:12:16俺らはお前と違って、プログラム書く以外に趣味持たないからな。
何故汚いコードが書かれるのか、何故適切にメソッド分割されないのか、その大きな原
因の一つとなっているのが、日本人にとっての英語なんじゃないかと俺は考えている。
その話はこの後するが、コードを書いていて、メソッド分割を躊躇させる要因として、以前
書いた引数の検討に加えて、ネーミングの煩わしさがある。既に手元に必要な情報が揃っ
ているのに、なぜわざわざわざ面倒な名前付けをしてメソッド分割しないといけないのか
と考える人が多いのだ。だらだら書くのは確かに楽なのだ。人は楽な方へ行きたがる。
特に納期に追われ気持ちに余裕が無い時は。
118 短文先生 :2007/02/15(木) 01:12:55因の一つとなっているのが、日本人にとっての英語なんじゃないかと俺は考えている。
その話はこの後するが、コードを書いていて、メソッド分割を躊躇させる要因として、以前
書いた引数の検討に加えて、ネーミングの煩わしさがある。既に手元に必要な情報が揃っ
ているのに、なぜわざわざわざ面倒な名前付けをしてメソッド分割しないといけないのか
と考える人が多いのだ。だらだら書くのは確かに楽なのだ。人は楽な方へ行きたがる。
特に納期に追われ気持ちに余裕が無い時は。
例えば、英語を母国語とする人達はメソッドを定義する時、恐らく我々日本人が、
買い物に行く（財布、買い物かご）
と書くぐらい（に近い）の気楽さで定義できるんじゃないかと思う。しかし我々がプログラミン
グする場合、このせっかくの思考を兎に角も英語(又はローマ字)に変換しなければならない。
goShopping ( ときて、えーと財布って英語でなんだっけ・・となる。結構面倒臭いのだ。これ
は我々にとっては大きなハンデだと思う。プログラミング言語が英語由来である以上（そして
実際、相性もいい）、仕方のないことではあるが、この英語という壁が、きれいなコードを書く
上で我々の前に立ちふさがる。メソッド定義を面倒なものにさせ、粘土細工に走らせる大き
な原因の一つとなっている。中には英語なんぞお構いなしに kaimonoNiIku(〜等とする兵も
いるが、それはそれでメソッド分割しないよりはよっぽどいいと思う。
119 短文先生 :2007/02/15(木) 01:13:35買い物に行く（財布、買い物かご）
と書くぐらい（に近い）の気楽さで定義できるんじゃないかと思う。しかし我々がプログラミン
グする場合、このせっかくの思考を兎に角も英語(又はローマ字)に変換しなければならない。
goShopping ( ときて、えーと財布って英語でなんだっけ・・となる。結構面倒臭いのだ。これ
は我々にとっては大きなハンデだと思う。プログラミング言語が英語由来である以上（そして
実際、相性もいい）、仕方のないことではあるが、この英語という壁が、きれいなコードを書く
上で我々の前に立ちふさがる。メソッド定義を面倒なものにさせ、粘土細工に走らせる大き
な原因の一つとなっている。中には英語なんぞお構いなしに kaimonoNiIku(〜等とする兵も
いるが、それはそれでメソッド分割しないよりはよっぽどいいと思う。
ネーミングの際に感じる煩わしさについては、メソッド名に限らず、変数名、クラス名など
についても同じだ。そしてそのために、errorFlagとか、checkError等といういかにもなダサ
い無意味な名前が世を闊歩することになるのだ。しかし、ここを面倒臭がってはいけない。
プログラミングを続けていると次第に分かってくると思うが、例えばメソッド名は動詞、或い
は動詞と目的語の組み合わせで大概なんとかなる。そして普段メソッド名に使う動詞の種類
は実はそれほど多くはない。is, has, set, get, create, generate, make, cut, setup, calculate,
move, copy, read, load, find, search, write, save, add, remove, modify, insert, update, delete,
restore, show, view, retrieve, push, pop, put, collect, sort, send, receive, ・・・結構あるな。ま
だあるか、でもせいぜいそんなもんだ。基本的な動詞だけだ。あとは業務独特の動詞類とか
だろう。そしてあとはこれに目的語をつなげて、calculateBonusとか、findGirlとか、saveMoney
とかするだけだ。或いは応用して、findBeautifulGirlとかgetMoneyByForceとかするだけだ。
120 短文先生 :2007/02/15(木) 01:14:23についても同じだ。そしてそのために、errorFlagとか、checkError等といういかにもなダサ
い無意味な名前が世を闊歩することになるのだ。しかし、ここを面倒臭がってはいけない。
プログラミングを続けていると次第に分かってくると思うが、例えばメソッド名は動詞、或い
は動詞と目的語の組み合わせで大概なんとかなる。そして普段メソッド名に使う動詞の種類
は実はそれほど多くはない。is, has, set, get, create, generate, make, cut, setup, calculate,
move, copy, read, load, find, search, write, save, add, remove, modify, insert, update, delete,
restore, show, view, retrieve, push, pop, put, collect, sort, send, receive, ・・・結構あるな。ま
だあるか、でもせいぜいそんなもんだ。基本的な動詞だけだ。あとは業務独特の動詞類とか
だろう。そしてあとはこれに目的語をつなげて、calculateBonusとか、findGirlとか、saveMoney
とかするだけだ。或いは応用して、findBeautifulGirlとかgetMoneyByForceとかするだけだ。
慣れてしまえば意外と簡単なものだ。もし分からない単語がでてきたら、辞書でひけばいい。
今は手軽にネットでもひける。言わばプログラミングとは無の世界に創造主たるプログラマー
が適切な言葉を創造しその言葉に意味を与えていく作業ともいえるのだ。
前回の例題の本当の狙いも実はそこにあった。メソッド分割の大切さを、とりあえずそこだけ
は理解して欲しいと俺は切に願う。メソッド分割をすることは慣れてくると楽しい作業でもある。
今まで述べた有益性はもちろん、将来も含めて自分の、或いはそのソースに関わるであろう
全ての人のための、ひいては全てのステークホルダーが幸せになるための作業なのだ。そし
てその結果は巡り巡って必ず自分に帰ってくる。おまけに英語の語彙力もつく。一石二鳥どこ
ろではない。目先の楽な道に走ってはいけないのだ。
121 短文先生 :2007/02/15(木) 01:17:41今は手軽にネットでもひける。言わばプログラミングとは無の世界に創造主たるプログラマー
が適切な言葉を創造しその言葉に意味を与えていく作業ともいえるのだ。
前回の例題の本当の狙いも実はそこにあった。メソッド分割の大切さを、とりあえずそこだけ
は理解して欲しいと俺は切に願う。メソッド分割をすることは慣れてくると楽しい作業でもある。
今まで述べた有益性はもちろん、将来も含めて自分の、或いはそのソースに関わるであろう
全ての人のための、ひいては全てのステークホルダーが幸せになるための作業なのだ。そし
てその結果は巡り巡って必ず自分に帰ってくる。おまけに英語の語彙力もつく。一石二鳥どこ
ろではない。目先の楽な道に走ってはいけないのだ。
・・・と、とりあえず俺が書いておきたかったことは大体書いたから、もう書かないかもしれな
い。気が向いたら書く。ひとまずお付き合いいただいた方には感謝。俺が偉そうに言えた義
理ではないけれど、美しいソースを書くのに必要なことは、プログラミングに関する好奇心と
向上心。そして他人への配慮だと思う。汚いソースというものは結構迷惑なものなのだ。俺は
犯罪に近いものだとさえ思っている。（汚い長文も・・・とつっこもうとしているお前。すまん、許
してくれ。）美しいプログラムとはバグのないプログラムのことではない。（いやそれも大事だ
が）また、殊更にテクニックに走ったプログラムのことでもない。仮にバグがあったとしてもその
原因を特定し易く、対処し易く、そして拡張し易いプログラムのことだ。
ということで、健闘を祈る。いやぜひ健闘してくれ。
125 仕様書無しさん :2007/02/17(土) 12:08:16い。気が向いたら書く。ひとまずお付き合いいただいた方には感謝。俺が偉そうに言えた義
理ではないけれど、美しいソースを書くのに必要なことは、プログラミングに関する好奇心と
向上心。そして他人への配慮だと思う。汚いソースというものは結構迷惑なものなのだ。俺は
犯罪に近いものだとさえ思っている。（汚い長文も・・・とつっこもうとしているお前。すまん、許
してくれ。）美しいプログラムとはバグのないプログラムのことではない。（いやそれも大事だ
が）また、殊更にテクニックに走ったプログラムのことでもない。仮にバグがあったとしてもその
原因を特定し易く、対処し易く、そして拡張し易いプログラムのことだ。
ということで、健闘を祈る。いやぜひ健闘してくれ。
こういうことって、誰かが教えりゃ簡単に理解できそうなもんだよな。
なのに、わかってる人はホントに少なくて、汚いソースが世にはびこる。
新人とかに教える側もこういうことわかってないから、教えられない。
その結果、ただ動くだけのコードしか書けないプログラマーの拡大再生産が進むわけだ。
なのに、わかってる人はホントに少なくて、汚いソースが世にはびこる。
新人とかに教える側もこういうことわかってないから、教えられない。
その結果、ただ動くだけのコードしか書けないプログラマーの拡大再生産が進むわけだ。
オススメの動画
今日の更新一覧
その他の記事
コメントありがとう御座います。⇒最新のコメントへ（18）
知恵熱がでそうです
>或いは応用して、findBeautifulGirlとかgetMoneyByForceとかするだけだ。
ここでｸｽﾘと来てしまったのは自分だけか。
ここでｸｽﾘと来てしまったのは自分だけか。
コード見ておっきしたり濡れたりするのが美しさです
国内向けなら買い物はkaimonoがでもいいんじゃね。
かっこよくしたけりゃXiでもやってればいい。
それより判りやすい方が大事だと思う。
美しいプログラムはまずソースの改行や
インデントがちゃんとされてる思う。
次に実行結果が整理されてて、
そのまま資料に使いまわしできたりするといいかと。
あとは最低限のメモリで動くとか無駄に長い変数名使わないとか
基本といえば基本だけど
かっこよくしたけりゃXiでもやってればいい。
それより判りやすい方が大事だと思う。
美しいプログラムはまずソースの改行や
インデントがちゃんとされてる思う。
次に実行結果が整理されてて、
そのまま資料に使いまわしできたりするといいかと。
あとは最低限のメモリで動くとか無駄に長い変数名使わないとか
基本といえば基本だけど
カーニハン先生の『ソフトウェア作法』『プログラム書法』『プログラミング作法』はコードを書く人間全てが読むべき本。前2つは扱ってる言語がFortranとかだけど、言わんとしていることはどの時代でもどの言語でも意識すべき普遍的なルールだと思う。
DIパターンとかO/Rマッピングも結構だけど、これら古典で言われていることを弁えていてくれないと話にならない。「てにおは」の使い方がおかしい人はどんなに素晴しいことを言ってても相手にされない、ってのを理解してない自称プログラマが多過ぎる。
DIパターンとかO/Rマッピングも結構だけど、これら古典で言われていることを弁えていてくれないと話にならない。「てにおは」の使い方がおかしい人はどんなに素晴しいことを言ってても相手にされない、ってのを理解してない自称プログラマが多過ぎる。
なんかためになるわｗ
引数も返値も当初考えてたとおりに完成する事なんてまず無いよな
中が美しい美しくないよりまずそこの変更が無いことを祈るしかないよな
中が美しい美しくないよりまずそこの変更が無いことを祈るしかないよな
パスタの写真ワロタ
心がけレベルの話をするとさ。文章書くのといっしょだよ。
自分以外の誰かが読むという前提で書けば
多少の癖はあっても改修するより書き直した方が早いなんて腐ったソースは書けない。
個人的にオススメテクニックとしてはコードを書く前にコメントを書く。
コメント書くにはソースの構成があらかじめ脳内できてないといけない。
全体の骨組みが確認できれば肉付けが下手糞でもそんな酷いことにはならない。
心がけレベルの話をするとさ。文章書くのといっしょだよ。
自分以外の誰かが読むという前提で書けば
多少の癖はあっても改修するより書き直した方が早いなんて腐ったソースは書けない。
個人的にオススメテクニックとしてはコードを書く前にコメントを書く。
コメント書くにはソースの構成があらかじめ脳内できてないといけない。
全体の骨組みが確認できれば肉付けが下手糞でもそんな酷いことにはならない。
さりげなくフィギュアの話が入っているのはなぜだろう。誤爆？
それ以外はむつかしくてのうがおいつけません･･･。
それ以外はむつかしくてのうがおいつけません･･･。
フィギュアの話入ってるはショート「プログラム」と掛けてるんだろ。
>>125に同意だが、何処も新人育成する余裕も、出来る様な人材もいねーよｗ
未経験おｋ研修ありで取って、研修せずに単体テストの仕様書と報告書書かせて、
新人全員エスケープってところを少なくとも2社知ってるｗ
>>125に同意だが、何処も新人育成する余裕も、出来る様な人材もいねーよｗ
未経験おｋ研修ありで取って、研修せずに単体テストの仕様書と報告書書かせて、
新人全員エスケープってところを少なくとも2社知ってるｗ
そういえばどこかで、DNAもスパゲッティコードだ、って紹介されてた。
使われていないと思われていた遺伝子が、実は他のどこかでつながっていたり、
その何十億と存在するコードが、それこそ途方も無い複雑な絡み方をしてるとか…
DNAを作ったヤツは、後から読むひとのことをもう少し考えてくれ！って話だったｗ
使われていないと思われていた遺伝子が、実は他のどこかでつながっていたり、
その何十億と存在するコードが、それこそ途方も無い複雑な絡み方をしてるとか…
DNAを作ったヤツは、後から読むひとのことをもう少し考えてくれ！って話だったｗ
>>1011
つまり動いてるのが不思議ってことかw
つまり動いてるのが不思議ってことかw
私の彼はプログラマーとかいうフラッシュはどこに消えたのだろうか。
>1011
無数のバグがありそうだなぁ。
(´-｀).oO(実は自分の存在がバグでｒｙ)
無数のバグがありそうだなぁ。
(´-｀).oO(実は自分の存在がバグでｒｙ)
うちの所の教授が一番綺麗だったって言ってたのは
途中から読み込んで別のコードとして認識できるコード
何かのOSのソースだったらしい
途中から読み込んで別のコードとして認識できるコード
何かのOSのソースだったらしい
不kぃイhgcccccfh所l;オk、抜く移住yhぃぉオ９;@オ９;@;ウ０@;ウ０;０;ﾎﾟﾎﾟpkllklp;９７lt６k７で５w４gdyt気球yついｙｔｇふｙｔｒｄｆぎゅい８７６５えわｓｄｆちゅいお９８７６５えｗｒちゅい８７６５えｒｒちゅ８
>>1013
これ？
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060314/232426/kobanashi.html?ST=swd-tech
CRLFとLFが混ざってるソースはかなりイライラしたなあ。
これ？
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060314/232426/kobanashi.html?ST=swd-tech
CRLFとLFが混ざってるソースはかなりイライラしたなあ。
この人が書いた本とか読んでみたいｗ
お気軽に一言お願いします。
⇒最初のコメントへ（18）
