좋은 Haskell 코딩 표준

좋은 Haskell 코딩 표준

---

누군가 Haskell의 좋은 코딩 표준에 대한 링크를 제공 할 수 있습니까? 나는 이것 과 이것을 찾았 지만 포괄적이지 않습니다. HaskellWiki에는 "클래스를주의해서 사용"과 "심볼 중위 식별자를 정의하는 것은 라이브러리 작성자에게만 맡겨야합니다"와 같은 "보석"이 포함되어 있다는 것은 말할 것도 없습니다.

---

정말 어려운 질문입니다. 귀하의 답변이 좋은 결과를 얻기를 바랍니다. 한편, 여기에 내가 초보자 용 코드에서 발견 한 실수 나 기타 성가신 일들의 목록이 있습니다. Kornel Kisielewicz가 가리키는 Cal Tech 스타일 페이지와 겹치는 부분이 있습니다. 내 조언 중 일부는 HaskellWiki "보석"만큼 모호하고 쓸모가 없지만 적어도 더 나은 조언이되기를 바랍니다. :-)

• 80 개의 열에 맞도록 코드 형식을 지정합니다. (고급 사용자는 87 또는 88을 선호 할 수 있습니다.

• 잊지 마세요 let바인딩 및 where조항은 정의의 상호 재귀 둥지 작성 하지 순서 정의합니다.

• 을 활용 where, 절 범위에 이미 (좋은 모호한 조언)있는 함수의 매개 변수를 볼 특히 자신의 능력을. 정말로 Haskell을 괴롭 히고 있다면, 당신의 코드는 where-bindings보다 더 많은 -bindings을 가져야합니다 let. let바인딩이 너무 많으면 재구성되지 않은 ML 프로그래머 또는 Lisp 프로그래머의 신호입니다.

• 중복 괄호를 사용하지 마십시오. 중복 된 괄호가 특히 불쾌한 곳은

  • if표현식 의 조건 주변 (당신을 재구성되지 않은 C 프로그래머로 표시)

  • 그 자체가 중위 연산자의 인수 인 함수 애플리케이션 주변 ( 함수 애플리케이션은 어떤 중위 연산자보다 더 긴밀 하게 결합 합니다.이 사실은 우리 공룡이 APL의 오른쪽에서 왼쪽 스캔 규칙을 가졌던 것과 거의 같은 방식으로 모든 Haskeller의 두뇌에 불타 오릅니다. 태워.)

• 중위 연산자 주위에 공백을 두십시오. 튜플 리터럴에서 각 쉼표 뒤에 공백을 넣으십시오.

• 인수가 괄호로 묶여 있더라도 함수와 인수 사이에 공백을 사용하십시오.

• $연산자를 신중하게 사용하여 괄호를 줄이십시오. $와 infix 사이의 밀접한 관계에 유의하십시오 ..

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

• 내장 Maybe및 Either유형을 간과하지 마십시오 .

• 쓰지 마십시오 if <expression> then True else False. 올바른 문구는 간단 <expression>합니다.

• head또는 tail패턴 일치를 사용할 수있을 때 사용하지 마십시오 .

• 중위 점 연산자로 함수 구성을 간과하지 마십시오.

• 줄 바꿈은 신중하게 사용하십시오. 줄 바꿈은 가독성을 높일 수 있지만 단점이 있습니다. 편집기는 한 번에 40 ~ 50 줄만 표시 할 수 있습니다. 한 번에 큰 함수를 읽고 이해해야한다면 줄 바꿈을 과도하게 사용해서는 안됩니다.

• 거의 항상 --주석보다 줄 끝까지 실행 되는 주석을 선호합니다 {- ... -}. 중괄호로 묶은 주석은 큰 헤더에 적합 할 수 있습니다.

• 각 최상위 함수에 명시 적 형식 서명을 제공합니다.

• 가능하면 인접한 줄에 나타나는 --선, =기호, 괄호와 쉼표를 정렬하십시오 .

• 내가 GHC 중앙의 영향을 받았기 camelCase때문에 내 보낸 식별자 에 사용 short_name하고 로컬 where바운드 또는 let바운드 변수에 밑줄 을 사용하는 것을 매우 선호 합니다.

---

엄지 손가락 imho의 몇 가지 좋은 규칙 :

• HLint 에 문의하여 중복 중괄호가 없는지, 그리고 코드가 무의미하게 전체가 아닌지 확인하십시오.
• 기존 라이브러리 함수를 다시 생성하지 마십시오. Hoogle 이 그들을 찾는 데 도움을 줄 수 있습니다.
  • 종종 기존 라이브러리 함수는 만들려는 것보다 더 일반적입니다. 당신이 원하는 경우 예를 들어 Maybe (Maybe a) -> Maybe a, 다음 join무엇보다도 그 작업을 수행합니다.
• 인수 이름 지정 및 문서화는 때때로 중요합니다.
  • 와 같은 함수 replicate :: Int -> a -> [a]의 경우 각 인수가 유형만으로 무엇을하는지 매우 분명합니다.
  • 같은 유형의 여러 인수를받는 함수의 경우 인수 isPrefixOf :: (Eq a) => [a] -> [a] -> Bool이름 지정 / 문서화가 더 중요합니다.
• 한 함수가 다른 함수를 제공하기 위해서만 존재하고 다른 방식으로는 유용하지 않거나 좋은 이름을 생각하기 어렵다면 아마도 where모듈의 범위 대신 호출자의 절 에 있어야합니다 .
• 마른
  • 적절한 경우 Template-Haskell을 사용하십시오.
  • 기능의 번들이 좋아 zip3, zipWith3, zip4, zipWith4, 등 매우 MEH 있습니다. 대신 s Applicative와 함께 스타일을 사용하십시오 ZipList. 당신은 아마 그런 기능이 정말로 필요하지 않을 것입니다.
  • 인스턴스를 자동으로 파생합니다. 파생 패키지는 다음과 같은 유형 클래스의 인스턴스를 도출 할 수 있습니다 Functor(유형의 인스턴스를 만들 수있는 단 하나의 올바른 방법이있다 Functor).
• 보다 일반적인 코드에는 몇 가지 이점이 있습니다.
  • 더 유용하고 재사용이 가능합니다.
  • 더 많은 제약이 있기 때문에 버그에 덜 취약합니다.
    • 예를 들어 concat :: [[a]] -> [a], 프로그램을 원하는 경우 join :: Monad m => m (m a) -> m a. join프로그래밍 concat할 때 실수로 목록을 뒤집을 수 join있고 할 수있는 일이 거의 없기 때문에 프로그래밍 할 때 오류의 여지가 적습니다 .
• 코드의 여러 위치에서 동일한 모나드 변환기 스택을 사용할 때 이에 대한 유형 동의어를 만드십시오. 이렇게하면 유형이 더 짧고 간결하며 일괄 수정이 더 쉬워집니다.
• "lazy IO"에주의하십시오. 예를 들어 readFile파일을 읽는 순간 파일의 내용을 실제로 읽지 않습니다.
• 코드를 찾을 수 없을 정도로 들여 쓰기를하지 마십시오.
• 유형이 논리적으로 유형 클래스의 인스턴스 인 경우 인스턴스로 만듭니다.
  • 인스턴스는 익숙한 것으로 고려했던 다른 인터페이스 기능을 대체 할 수 있습니다.
  • 참고 : 논리적 인스턴스가 두 개 이상인 경우 인스턴스에 대한 newtype-wrapper를 만듭니다.
  • 다른 인스턴스를 일관되게 만드십시오. 목록이 다음 Applicative과 같이 작동 한다면 매우 혼란 스럽거나 나쁠 것 ZipList입니다.

---

이 스타일 검사기를 살펴 보는 것이 좋습니다 .

---

• 다음과 같은 작업을 통해 가능한 한 포인트없는 스타일 구성으로 함수를 구성하려고합니다.

  func = boo . boppity . bippity . snd
      where boo = ...
            boppity = ...
            bippity = ...
  

• I like using ($) only to avoid nested parens or long parenthesized expressions

• ... I thought I had a few more in me, oh well

---

I found good markdown file covering almost every aspect of haskell code style. It can be used as cheat sheet. You can find it here: link

참고URL : https://stackoverflow.com/questions/1983047/good-haskell-coding-standards