请问函数式编程授权新的命名约定？(Does functional programming manda

2019-08-18 01:01发布

站内文章 / 前沿技术

75 0

男人必须洒脱

女 | 书童

私信

我最近开始学习使用Haskell的函数式编程和这篇文章的官方哈斯克尔维基在传来：如何阅读哈斯克尔。

文章声称，短的变量名，如x ， xs ，和f是拟合因为简洁和抽象为Haskell代码。从本质上讲，它声称函数式编程是从其他范式的命名约定不适用这样一个独特的范例。

你对这个想法？

Answer 1:

在函数式编程范式，人们通常构造抽象不仅自上而下的 ，也是自下而上 。这意味着你基本上增强宿主语言。在这种情况我见简洁命名为适当。 Haskell语言已经是简洁和表现，所以你应该是种习惯了。

然而，试图在一定的领域模型的时候，我不相信简洁的名字都不错，即使在函数体很小。领域知识应该反映在命名。

只是我的观点。

在回答您的意见

我要两个代码段从真实世界哈斯克尔，无论是从第3章。

在命名为“节更受控的方法 ”，作者提出，它返回一个列表的第二个元件的功能。他们的最终版本是这样的：

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

该功能一般就够了，由于类型参数a ，我们正在作用于一个内置的类型，所以我们并不真正关心的第二个元素实际上是事实。我相信， x是足够在这种情况下。就像在一个小的数学公式。

在另一方面，在名为“一节介绍的局部变量 ”，他们正在写，试图一小块银行领域的模型的示例功能：

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

肯定是不推荐使用此短变量名。事实上，我们关心的金额表示。

Answer 2:

我想，如果参数的语义是代码的上下文中明确，那么你可以逃脱短变量名。我经常在C＃中的lambda表达式中使用这些出于同样的原因。但是，如果它是不明确的，你应该与命名更加明确。

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);

但在这种情况下，它似乎更适合来命名变量，因为它不是立即显现出来什么总结在做什么。

基本上，我认为不要过于担心，除非公约是绝对必要的，以防止人们搞砸了。如果你必须在做任何选择，用什么在你工作的环境（语言，团队，代码块）是有道理的，并会被人理解后来别人看完小时，周或数年。别的只是浪费时间的强迫症。

Answer 3:

我认为作用域是排名第一的原因。在命令式语言，动态变量，特别是全球的人需要适当命名的，因为它们可以在几个功能使用。随着词汇范围，很明显是什么符号在编译时必然。

不变性也有助于这如C / C ++ /爪哇传统语言一些extent-，可变可以在时间表示在不同的点不同的数据。因此，它需要被赋予一个名称为程序员其功能的想法。

就个人而言，我觉得功能，如一流的功能特性使得符号名漂亮的冗余。在传统的语言，很容易涉及到的象征; 基于它的使用，我们可以知道它是数据或函数。

Answer 4:

我正在学习哈斯克尔了，但我不认为它的命名约定是多大的不同。当然，在Java中你很难找到一个名字，如xs 。但它是很容易找到类似的名字x在一些数学函数， i ， j的计数器等。我认为这样的名字是在正确的上下文中完全恰当。 xs在Haskell是名单上唯一合适的通用功能。有哈斯克尔他们中的很多，所以这个名字是广泛的传播。 Java不提供简单的方法来处理这样一个通用的抽象，这就是为什么对列表的名称（并列出本身）通常更具体的，如lists或users 。

Answer 5:

我只是参加了一些，有很多代码样本对哈斯克尔会谈。随着多头的代码处理X，I和F的命名没有打扰我。然而，当我们坐进重型列表操作之类，我发现这三个字母或这样的名字是一个很大的可读性比我更喜欢。

为了公平起见命名的显著部分遵循一套规范的，所以我认为，一旦你进入行话这将是一个更容易一些。

幸运的是，没有什么可以阻止我们使用有意义的名称，但我不同意，语言本身在某种程度上使得三个字母标识符有意义的大多数人。

Answer 6:

在罗马做到入乡随俗

（或者因为他们在我镇说：“东德fueres，HAZ老阙vieres”）

Answer 7:

凡是有助于可读性是一件好事 - 因此有意义的名称是在任何语言是一件好事。

我用很多语言简短的变量名，但他们保留的东西并不在代码或其中的含义是在上下文清楚的整体意义重大。

我会小心多远我大概花了Haskell的名字的建议

Answer 8:

我的Haskell的做法仅仅是平庸的水平，因此，我就敢尝试回复只有第二，你的问题的更普遍的一部分：

“ 本质上，它声称功能的编程是从其他范例的命名约定不适用这样的不同的范例。”

我怀疑，答案是“是”，但我的背后动机的意见仅是在短短一个单一的功能性的语言经验的限制。不过，这可能是有趣的，因为这是一个非常简约的一个，因此，理论上很“纯”，和潜在的大量的实用功能性的语言。

我是古玩它是多么容易上写上这样的“非常”简约的函数式编程语言如切实可行的方案组合逻辑。

当然，函数式编程语言缺乏可变的变量，但是组合的逻辑“走得更远一步多个”，它甚至缺乏正式的参数。它没有任何语法糖，它没有任何预先定义的数据类型，甚至布尔或数字。一切都必须通过组合程序进行模仿，并上溯到只有两个基本的组合子的应用。

尽管这种极端的极简主义，仍然有一个整洁和舒适的方式进行“编程”组合逻辑的实用方法。我已经写了奎因在其模块化和可重复使用的方式，它不会讨厌甚至引导一个自我解释就可以了。

对于总结，我觉得在使用这种极其简约的函数式编程语言的特点如下：

有必要去创造了很多的辅助功能。在Haskell，存在大量的语法糖（模式匹配，形参）。您可以在几行字写的相当复杂的功能。但是，在组合的逻辑，这可能在Haskell由单个函数表达的任务，必须精心挑选的辅助功能来代替。替换的Haskell语法糖的负担采取在组合逻辑巧妙选择辅助功能。 至于回答你原来的问题：这是值得发明了有意义的和吸引人的名字的辅助功能，这些军团，因为他们可以在许多进一步的上下文相当强大的 ， 可重复使用 ，有时以意想不到的方式。
此外，组合逻辑的程序员不仅被迫找一堆巧妙地选用辅助功能的上口的名字，但甚至更多，他是被迫（重新）创造全新的理论 。例如，对于模仿列表，程序员被迫与他们的模拟天生它们折叠功能 S，基本上，他（重新）创造catamorphisms，深代数和范畴论的概念。

我猜想，有几个差异可以追溯到一个事实，即函数式语言有一个强大的“胶水” 。