Good Haskell编码标准 [英] Good Haskell coding standards

问题描述

有人可以提供一个链接到一个好的编码标准Haskell吗？我找到了此和这，但他们远不全面。更何况HaskellWiki包含了gems作为use classes with care和定义符号中缀标识符只应该留给库的作者。

解决方案

真的很难的问题。我希望你的答案好起来。同时，这里有一个目录的错误或其他恼人的事情，我在初学者的代码中找到。与Kornel Kisielewicz指的Cal Tech风格页面有一些重叠。我的一些建议是有点像HaskellWiki宝石一样模糊和无用，但我希望至少它是更好的建议： - ）

• 格式化代码，使其适合80列。




• 不要忘记让 bindings和其中子句创建定义的相互递归的嵌套 p>




• 利用 where 子句，特别是能够查看已经在范围内的函数参数咨询）。如果你真的是Haskell，你的代码应该有更多其中 -bindings比 let -bindings。太多 let -bindings是未经重构的ML程序员或Lisp程序员的标志。




• 括号。有些重复括号特别令人反感的地方是

  
  
  
  
  

  • $ c> expression（将您定义为未经构造的C程序员）

  
  

  • 在函数应用程序本身的后缀操作符这个事实应该被烧成每个Haskeller的大脑，就像我们的恐龙APL的从右到左的扫描规则被烧毁一样。）

  
  



• 将空格放在中缀运算符上。




• 在函数及其参数之间添加空格，即使参数括号。




• 使用 $ 操作符明智地减少括号。请注意 $ 和中缀之间的密切关系。：

    f $ g $ hx ==（f。g。h）x == f。 G 。 h $ x 
    




• 不要忽视内置的 Maybe




• 不要写 ;正确的短语只是< expression> 。




• 不要使用




• Don




• 仔细使用换行符。换行符可以提高可读性，但是有一个折衷：您的编辑器可以一次只显示40-50行。




• 几乎总是喜欢 - 注释运行到 { - ... - } 注释行尾。




• 给每个顶级函数一个明确的类型签名。




• 如果可能，对齐 - 行， = 符号，




• 由于我是GHC的中心，我有一个非常轻微的偏好使用 camelCase 用于导出的标识符和 short_name 下划线为其中 > let - 绑定变量。

Could someone provide a link to a good coding standard for Haskell? I've found this and this, but they are far from comprehensive. Not to mention that the HaskellWiki one includes such "gems" as "use classes with care" and "defining symbolic infix identifiers should be left to library writers only."

解决方案

Really hard question. I hope your answers turn up something good. Meanwhile, here is a catalog of mistakes or other annoying things that I have found in beginners' code. There is some overlap with the Cal Tech style page that Kornel Kisielewicz points to. Some of my advice is every bit as vague and useless as the HaskellWiki "gems", but I hope at least it is better advice :-)

• Format your code so it fits in 80 columns. (Advanced users may prefer 87 or 88; beyond that is pushing it.)

• Don't forget that let bindings and where clauses create a mutually recursive nest of definitions, not a sequence of definitions.

• Take advantage of where clauses, especially their ability to see function parameters that are already in scope (nice vague advice). If you are really grokking Haskell, your code should have a lot more where-bindings than let-bindings. Too many let-bindings is a sign of an unreconstructed ML programmer or Lisp programmer.

• Avoid redundant parentheses. Some places where redundant parentheses are particularly offensive are

  • Around the condition in an if expression (brands you as an unreconstructed C programmer)

  • Around a function application which is itself the argument of an infix operator (Function application binds tighter than any infix operator. This fact should be burned into every Haskeller's brain, in much the same way that us dinosaurs had APL's right-to-left scan rule burned in.)

• Put spaces around infix operators. Put a space following each comma in a tuple literal.

• Prefer a space between a function and its argument, even if the argument is parenthesized.

• Use the $ operator judiciously to cut down on parentheses. Be aware of the close relationship between $ and infix .:

  f $ g $ h x == (f . g . h) x == f . g . h $ x
  

• Don't overlook the built-in Maybe and Either types.

• Never write if <expression> then True else False; the correct phrase is simply <expression>.

• Don't use head or tail when you could use pattern matching.

• Don't overlook function composition with the infix dot operator.

• Use line breaks carefully. Line breaks can increase readability, but there is a tradeoff: Your editor may display only 40–50 lines at once. If you need to read and understand a large function all at once, you mustn't overuse line breaks.

• Almost always prefer the -- comments which run to end of line over the {- ... -} comments. The braced comments may be appropriate for large headers—that's it.

• Give each top-level function an explicit type signature.

• When possible, align -- lines, = signs, and even parentheses and commas that occur in adjacent lines.

• Influenced as I am by GHC central, I have a very mild preference to use camelCase for exported identifiers and short_name with underscores for local where-bound or let-bound variables.

这篇关于Good Haskell编码标准的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！