[過去ﾛｸﾞ]
関数型プログラミング言語Haskell Part16 (978ﾚｽ)
上
下
前
次
1-
新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
161
:
デフォルトの名無しさん
[sage] 2011/10/15(土) 19:17:23.16
AA×
>>157
>>156
[240|
320
|
480
|
600
|
100%
|
JPG
|
べ
|
ﾚｽ栞
|
ﾚｽ消
]
161: デフォルトの名無しさん [sage] 2011/10/15(土) 19:17:23.16 >>157 では、mapAdj や mapN (N = Neighborhood) で >>156 「名前と型両方に無駄なく意味をこめる」 なるほど、そういう考え方もあるのですね わたしは、改めてこの関数を使うプログラマの立場に立って考えてみると、 型シグネチャはライブラリ ドキュメントを見ることでしか確認はせず、 普段ソース中でこの関数を使っている時は関数名しか見ないと思いました そして、ライブラリ ドキュメントはソースに比べてそう頻繁に見るものではない （自分がそうなので） だからソースを眺めた時、この関数を使っているところで、 「何がどのような結果になるのか」という情報が仕舞われた頭の抽斗が開けやすくなる、 抽斗の場所がぱっと思い浮かぶようなキーワードがいいなと ポイントフリーで使っていると余計にそう感じます というわけで、私はむしろ型シグネチャで分かる意味・ニュアンスも、 積極的に関数名に入れていこうと、皆さんの意見を聞いて思いました http://echo.5ch.net/test/read.cgi/tech/1317958045/161
では や で 名前と型両方に無駄なく意味をこめる なるほどそういう考え方もあるのですね わたしは改めてこの関数を使うプログラマの立場に立って考えてみると 型シグネチャはライブラリ ドキュメントを見ることでしか確認はせず 普段ソース中でこの関数を使っている時は関数名しか見ないと思いました そしてライブラリ ドキュメントはソースに比べてそう頻繁に見るものではない 自分がそうなので だからソースを眺めた時この関数を使っているところで 何がどのような結果になるのかという情報が仕舞われた頭の抽斗が開けやすくなる 抽斗の場所がぱっと思い浮かぶようなキーワードがいいなと ポイントフリーで使っていると余計にそう感じます というわけで私はむしろ型シグネチャで分かる意味ニュアンスも 積極的に関数名に入れていこうと皆さんの意見を聞いて思いました
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 817 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
ぬこの手
ぬこTOP
0.050s