34

私は最近、Haskell を使用した関数型プログラミングの勉強を始め、公式の Haskell wiki で次の記事にたどり着きました: How to read Haskell .

xこの記事では、xs、 、などの短い変数名fは、簡潔さと抽象化のために Haskell コードに適していると主張しています。本質的に、関数型プログラミングは非常に明確なパラダイムであるため、他のパラダイムの命名規則は適用されないと主張しています。

これについてどう思いますか？

4

10 に答える 10

34

関数型プログラミングのパラダイムでは、通常、トップダウンだけでなくボトムアップでも抽象化を構築します。つまり、基本的にホスト言語を強化します。この種の状況では、簡潔な名前付けが適切であると考えています。Haskell 言語はすでに簡潔で表現力豊かなので、ある程度慣れているはずです。

ただし、特定のドメインをモデル化しようとする場合、関数本体が小さい場合でも、簡潔な名前は適切ではないと思います。ドメインの知識はネーミングに反映されるべきです。

私の意見です。

あなたのコメントに応えて

Real World Haskellから 2 つのコード スニペットを取り上げます。どちらも第 3 章からのものです。

「より制御されたアプローチ」という名前のセクションで、著者はリストの 2 番目の要素を返す関数を提示します。彼らの最終版はこれです：

tidySecond :: [a] -> Maybe a
tidySecond (_:x:_) = Just x
tidySecond _       = Nothing

この関数は、型パラメーターaと組み込み型で動作しているという事実により、十分に汎用的であるため、2 番目の要素が実際に何であるかはあまり気にしません。xこの場合は十分だと思います。ちょっとした数式のように。

一方、「ローカル変数の紹介」という名前のセクションでは、銀行ドメインの小さな部分をモデル化しようとする関数の例を書いています。

lend amount balance = let reserve    = 100
                          newBalance = balance - amount
                      in if balance < reserve
                         then Nothing
                         else Just newBalance

ここで短い変数名を使用することはお勧めできません。私たちは実際に、それらの金額が何を表しているかを気にしています。

于 2009-10-14T07:35:31.853 に答える
16

引数のセマンティクスがコードのコンテキスト内で明確であれば、短い変数名で逃げることができると思います。同じ理由で、これらをC＃ラムダでよく使用します。ただし、あいまいな場合は、名前をより明確にする必要があります。

map                     :: (a->b) -> [a] -> [b]
map f  []               =  []
map f (x:xs)            =  f x : map f xs

Haskellに触れたことがない人にとっては、それは醜い、保守不可能なコードのように見えるかもしれません。しかし、ほとんどのHaskellプログラマーはこれをすぐに理解するでしょう。だからそれは仕事を成し遂げます。

var list = new int[] { 1, 2, 3, 4, 5 };
int countEven = list.Count(n => n % 2 == 0)

その場合、短い変数名が適切と思われます。

list.Aggregate(0, (total, value) => total += value);

ただし、この場合、Aggregateが何を行っているかがすぐにはわからないため、変数に名前を付ける方が適切と思われます。

基本的に、人を台無しにすることが絶対に必要でない限り、慣習についてあまり心配しないと思います。問題に選択肢がある場合は、作業しているコンテキスト（言語、チーム、コードのブロック）で意味のあるものを使用し、数時間、数週間、または数年後に他の誰かがそれを読んで理解できるようにします。それ以外のものは、時間の無駄なOCDです。

于 2009-10-14T07:53:45.170 に答える
8

スコーピングがこれの一番の理由だと思います。命令型言語では、動的変数、特にグローバル変数は複数の関数で使用されるため、適切に名前を付ける必要があります。レキシカルスコープを使用すると、コンパイル時にシンボルが何にバインドされているかが明確になります。

不変性もこれにある程度貢献します。C/C++/Java などの従来の言語では、変数は異なる時点で異なるデータを表すことができます。したがって、プログラマーがその機能を理解できるように名前を付ける必要があります。

個人的には、ファーストクラス関数のような機能はシンボル名をかなり冗長にしていると感じています。伝統的な言語では、シンボルに関連付ける方が簡単です。その使用法に基づいて、それがデータなのか関数なのかを判断できます。

于 2009-10-14T07:36:15.517 に答える
7

私は現在 Haskell を勉強していますが、その命名規則はそれほど異なっているとは思いません。もちろん、Java では のような名前を見つけることはほとんどありませんxs。xしかし、いくつかの数学関数のiような名前を見つけるのは簡単jです. xsHaskell では、リストに対するジェネリック関数のみが適切です。Haskell にはたくさんあるので、この名前は広く普及しています。Java は、このような一般的な抽象化を処理する簡単な方法を提供していません。そのため、リスト (およびリスト自体) の名前は通常、より具体的です (例: listsor ) users。

于 2009-10-14T07:44:31.573 に答える
3

ローマにいるときは、ローマ人と同じようにしてください

（または彼らが私の町で言うように： "Donde fueres、haz lo que vieres"）

于 2009-10-14T08:24:21.883 に答える
3

たくさんのコードサンプルを使って、Haskellに関する多くの講演に参加しました。コードがx、i、fを処理している限り、名前は気になりませんでした。しかし、ヘビーデューティーリストの操作などに入るとすぐに、3文字ほどの名前が私が好むよりもはるかに読みにくいことに気づきました。

公平を期すために、命名の重要な部分は一連の規則に従っているので、用語に入ると少し簡単になると思います。

幸いなことに、意味のある名前を使用することを妨げるものは何もありませんが、言語自体がどういうわけか3文字の識別子を大多数の人々にとって意味のあるものにすることに同意しません。

于 2009-10-14T07:55:16.040 に答える
2

読みやすさを支援するものは何でも良いことです。したがって、意味のある名前はどの言語でも良いことです。

私は多くの言語で短い変数名を使用していますが、それらはコードの全体的な意味において重要ではないもの、またはコンテキストで意味が明確な場合のために予約されています。

Haskell の名前についてのアドバイスをどこまで取り入れたかには注意が必要です

于 2009-10-14T07:37:48.870 に答える
1

Haskell では、型よりも変数名の方が意味が伝わりません。純粋に関数型であることには、コンテキストに関係なく、任意の式の型を要求できるという利点があります。

于 2009-10-15T06:29:10.907 に答える
0

引数の命名についてここで述べられている多くの点に同意しますが、「ページで検索」をすばやく実行すると、誰も暗黙のプログラミング(無意味/無意味) について言及していないことがわかります。これが読みやすいかどうかは議論の余地があるため、あなたとあなたのチーム次第ですが、徹底的に検討する価値があることは間違いありません.

名前付き引数なし = 引数の命名規則なし。

于 2010-04-04T11:35:35.317 に答える