Хтось може надати посилання на хороший стандарт кодування для Haskell? Я знайшов це і це , але вони далеко не всеосяжні. Не кажучи вже про те, що HaskellWiki включає такі "дорогоцінні камені", як "обережно користуватися класами" і "визначення символічних ідентифікаторів інфіксів слід залишати лише авторам бібліотек".
Відповіді:
Справді важке питання. Сподіваюся, ваші відповіді виявлять щось хороше. Тим часом, ось каталог помилок чи інших прикрих речей, які я знайшов у коді для початківців. Існує деяке накладання на сторінку стилю Cal Tech, на яку вказує Корнель Кіселевич. Деякі мої поради настільки ж невизначені та марні, як "коштовні камені" HaskellWiki, але я сподіваюся, що принаймні це краща порада :-)
Відформатуйте свій код, щоб він містив 80 стовпців. (Досвідчені користувачі можуть віддати перевагу 87 або 88; крім того, що це вимагає).
Не забувайте , що letпалітурки і whereположення створюють взаємно рекурсивне гніздо визначень, НЕ послідовність визначень.
Скористайтеся перевагами where, особливо їх здатністю бачити параметри функцій, які вже входять до сфери застосування (приємна невизначена порада). Якщо ви справді маркуєте Haskell, ваш код повинен мати набагато більше whereприв'язок, ніж letприв'язок. Занадто багато letприв'язок - ознака нереконструйованого програміста ML або програміста Lisp.
Уникайте зайвих дужок. Деякі місця, де зайві дужки особливо образливі, є
Навколо умови у ifвиразі (клеймить вас як нереконструйованого програміста на С)
Навколо функціональної програми, яка сама є аргументом інфіксного оператора ( функціональна програма зв'язується сильніше, ніж будь-який інфіксний оператор . Цей факт повинен бути вписаний у мозок кожного Хаскеллера, приблизно так само, як і у нас, динозаврів, правило сканування справа наліво APL спалений.)
Розташуйте пробіли навколо інфіксних операторів. Поставте пробіл після кожної коми у літералі кортежу.
Віддайте перевагу пробілу між функцією та її аргументом, навіть якщо аргумент має дужки.
Використовуйте $оператор розумно, щоб скоротити дужки. Пам’ятайте про тісний взаємозв’язок між $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змінних.
(length l) + 1це потворно. Застосування lengthавтоматично пов'язує жорсткіше, ніж додаток +, тому ідіоматичним є те, що потрібно писати length l + 1. Дужки - це загроза функціональних програм.
Format your code so it fits in 80 columns.Я більше віддаю перевагу 120 кол .. ніби ніколи ніколи не вміщується у 80.
Кілька хороших правил великих пальців imho:
Maybe (Maybe a) -> Maybe a, то joinце робить серед іншого.replicate :: Int -> a -> [a]досить очевидно, що робить кожен з аргументів, лише на основі їх типів.isPrefixOf :: (Eq a) => [a] -> [a] -> Bool, імена / документація аргументів важливіша.whereпункті свого абонента, а не в області дії модуля.zip3, zipWith3, zip4, zipWith4і т.д. дуже Мех. Замість цього використовуйте Applicativeстиль із ZipLists. Напевно, вам ніколи не потрібні такі функції.Functor(існує лише один правильний спосіб зробити тип екземпляром Functor).concat :: [[a]] -> [a], і зверніть увагу, як це може бути більш загальним як join :: Monad m => m (m a) -> m a. Менше місця для помилок при програмуванні, joinоскільки під час програмування concatви можете помилково змінити списки, і joinтам дуже мало речей, які ви можете зробити.readFileнасправді не читає вміст файлу на момент його прочитання.Applicativeповодився так ZipList.Мені подобається намагатися якомога більше організувати функції як безточкові композиції, роблячи такі речі:
func = boo . boppity . bippity . snd
where boo = ...
boppity = ...
bippity = ...
Мені подобається використовувати ($) лише для того, щоб уникнути вкладених парен або довгих виразів у дужках
... Я думав, що в мене є ще кілька, ну добре
Я б запропонував поглянути на цю перевірку стилів .