功能编程是否需要新的命名约定？ [英] Does functional programming mandate new naming conventions?

问题描述

我最近开始使用Haskell学习函数式编程，并在Haskell官方wiki上发表了这篇文章：如何阅读Haskell 。

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

你对这个有什么想法？

解决方案

在函数式编程范式中，人们通常不仅自上而下构建抽象， =http://www.paulgraham.com/progbot.html =nofollow noreferrer> 自下而上 。这意味着你基本上增强了主机语言。在这种情况下，我看到适当的命名。 Haskell语言已经很简洁和表达，所以你应该习惯它。

但是，当试图建模一个域，我不相信简洁名称是好的，即使当函数体小时。

回应您的意见

<

我将从 Real World Haskell 获取两个代码段>，均来自第3章。

在名为一个更受控的方法，作者提出了一个返回列表的第二个元素的函数。他们的最终版本是：

  tidySecond :: [a]  - >也许a 
 tidySecond（_：x：_）= Just x 
 tidySecond _ =没有
  

$ b b

这个函数是通用的，因为类型参数 a 和事实上我们在内置类型，所以我们不在乎第二个元素实际上是什么。我相信 x 就足够了。就像在一个小的数学方程。

另一方面，在名为简介局部变量，他们正在编写一个示例函数，尝试对一小块银行域建模： / p>

 借出余额= let reserve = 100 
 newBalance = balance- amount 
如果余额< reserve 
 then Nothing 
 else just newBalance 
  

不建议。我们实际上关心这些金额代表什么。

I recently started studying functional programming using Haskell and came upon this article on the official Haskell wiki: How to read Haskell.

The article claims that short variable names such as x, xs, and f are fitting for Haskell code, because of conciseness and abstraction. In essence, it claims that functional programming is such a distinct paradigm that the naming conventions from other paradigms don't apply.

What are your thoughts on this?

解决方案

In a functional programming paradigm, people usually construct abstractions not only top-down, but also bottom-up. That means you basically enhance the host language. In this kind of situations I see terse naming as appropriate. The Haskell language is already terse and expressive, so you should be kind of used to it.

However, when trying to model a certain domain, I don't believe succinct names are good, even when the function bodies are small. Domain knowledge should reflect in naming.

Just my opinion.

In response to your comment

I'll take two code snippets from Real World Haskell, both from chapter 3.

In the section named "A more controlled approach", the authors present a function that returns the second element of a list. Their final version is this:

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

The function is generic enough, due to the type parameter a and the fact we're acting on a built in type, so that we don't really care what the second element actually is. I believe x is enough in this case. Just like in a little mathematical equation.

On the other hand, in the section named "Introducing local variables", they're writing an example function that tries to model a small piece of the banking domain:

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

Using short variable name here is certainly not recommended. We actually do care what those amounts represent.

这篇关于功能编程是否需要新的命名约定？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！