Хороший Haskell, кодирующий стандарты

Я бы посоветовал взглянуть на эту проверку стиля .

• Мне нравится пытаться организовать функции. такие же бесточечные стилевые композиции, как насколько это возможно, делая вещи например:

  func = boo . boppity . bippity . snd
   где бу = ...
   боппити = ...
   бипити = ...
  

• Мне нравится использовать ($) только для того, чтобы избежать вложенных парен или длинных выражений в круглых скобках

• .... Я думал, что во мне есть еще несколько, о ну

Некоторые хорошие правила imho:

• Проконсультируйтесь с HLint, чтобы убедиться, что у вас нет лишних скобок и что ваш код не бессмысленно точечно заполнен.
• Избегайте воссоздания существующих библиотечных функций. Hoogle может помочь вам найти их.
  • Часто существующие библиотечные функции являются более общими, чем то, что вы собирались сделать. Например, если вы хотите, чтобы -> Может быть, a, тогда join делает это, кроме всего прочего.
• Иногда важным является именование аргументов и документация.
  • Для функции типа повторить :: Int -> a -> [a] довольно очевидно, что делает каждый из аргументов, только из их типов.
  • Для функции, которая принимает несколько аргументов одного типа, например isPrefixOf :: (Eq a) => [a] -> [a] -> Bool, более важным является именование/документирование аргументов.
• Если одна функция существует только для обслуживания другой функции, и в противном случае она не является полезной, и/или трудно придумать для неё хорошее имя, то, вероятно, она должна существовать в пункте вызова , где, а не в области действия модуля.
• DRY.
  • При необходимости используйте шаблон Хаскелл.
  • Комплекты функций типа zip3, zipWith3, zip4, zipWith4 и т.д. и т.п. очень эффективны. Вместо этого используйте Applicative с ZipLists. Вероятно, вам никогда не понадобятся такие функции, как эти.
  • Автоматически создавайте экземпляры. Пакет derive может помочь вам получить экземпляры для таких классов типа как Functor (есть только один правильный способ сделать тип экземпляром Functor).
• Код, который является более общим, имеет несколько преимуществ:
  • Он более полезен и может быть использован многократно.
  • Он менее подвержен ошибкам, так как имеет больше ограничений.
    • Например, если вы хотите запрограммировать concat :: [[a]]. -> [a] , и обратите внимание на то, как это может быть более общим, так как присоединяется :: Monad m => m (m a) -> m a. При программировании join меньше места для ошибок, т.к. при программировании concat можно по ошибке перевернуть списки, а в join сделать очень мало.
• При использовании одного и того же стека трансформаторов monad во многих местах Вашего кода, сделайте для него синоним типа. Это сделает типы короче, лаконичнее и легче модифицировать массово.
• Остерегайтесь "ленивого ввода-вывода". Например, readFile на самом деле не читает содержимое файла в момент чтения файла.
• Избегайте отступов настолько, что я не могу найти код.
• Если ваш тип логически является экземпляром класса типа, то сделайте его экземпляром.
  • Экземпляр может заменить другие интерфейсные функции, которые вы, возможно, уже рассмотрели, на знакомые.
  • Замечание: Если существует более одного логического экземпляра, создайте для экземпляров обертку нового типа.
  • Сделайте различные экземпляры согласованными. Было бы очень запутано/ошибочно, если бы список Applicative вел себя как ZipList.