Функциональное программирование передает под мандат новые соглашения о присвоении имен?
Необходимо разработать параллелизм для программы. SQLite имеет четкие ограничения, и необходимо повиноваться им, видеть FAQ (также следующий вопрос).
10 ответов
Я только что посетил несколько лекций по Haskell с большим количеством примеров кода. Пока код имел дело с x, i и f, именование меня не беспокоило. Однако, как только мы перешли к тяжелым манипуляциям со списками и тому подобному, я обнаружил, что имена из трех букв или около того гораздо менее читабельны, чем я предпочитаю.
Чтобы быть справедливым, значительная часть именования следовала ряду соглашений, поэтому я предполагаю, что как только вы перейдете на жаргон, это будет немного проще.
К счастью, ничто не мешает нам использовать значимые имена, но я не согласен с тем, что сам язык каким-то образом делает трехбуквенные идентификаторы значимыми для большинства людей.
Находясь в Риме, поступайте, как римляне
(Или, как говорят в моем городе: «Donde fueres, haz lo que vieres»)
В Haskell значение передается меньше с помощью имен переменных, чем с помощью типов . То, что чисто функционально, имеет то преимущество, что можно запросить тип любого выражения, независимо от контекста.
Я сейчас изучаю Haskell, но мне не кажется, что его соглашения об именах сильно отличаются. Конечно, в Java вряд ли можно встретить такие имена, как xs . Но легко найти такие имена, как x в некоторых математических функциях, i , j для счетчиков и т. Д. Я считаю такие имена совершенно уместными в правильном контексте. . xs в Haskell подходит только для общих функций над списками. В Haskell их очень много, поэтому это название широко распространено. В Java нет простого способа обработки таких общих абстракций, поэтому имена списков (и сами списки) обычно более конкретны, например, списки или пользователи .
Я думаю, если семантика аргументов понятны в контексте кода, тогда вы можете обойтись короткими именами переменных. Я часто использую их в лямбдах C # по той же причине. Однако, если он неоднозначен, вы должны быть более явными с именами.
map :: (a->b) -> [a] -> [b]
map f [] = []
map f (x:xs) = f x : map f xs
Для кого-то, кто не имел никакого отношения к Haskell, это может показаться уродливым, неподдерживаемым кодом. Но большинство программистов на Haskell сразу поймут это. Так что он выполняет свою работу.
var list = new int[] { 1, 2, 3, 4, 5 };
int countEven = list.Count(n => n % 2 == 0)
В этом случае короткое имя переменной кажется подходящим.
list.Aggregate(0, (total, value) => total += value);
Но в этом случае кажется более подходящим называть переменные, потому что не сразу видно, что делает агрегат.
В принципе, я считаю, что не стоит слишком беспокоиться об условности, если только это не является абсолютно необходимым, чтобы люди не облажались. Если у вас есть выбор в этом вопросе, используйте то, что имеет смысл в контексте (язык, команда, блок кода), над которым вы работаете, и будет понятно для кого-то, читающего его через несколько часов, недель или лет. Все остальное - это просто бесполезная трата времени.
Моя практика Haskell находится на среднем уровне, поэтому я осмеливаюсь попытаться ответить только вторая, более общая часть Вашего вопроса:
" По сути, он утверждает, что функциональное программирование - это настолько отличная парадигма, что соглашения об именах из других парадигм неприменимы. "
I Подозреваю, ответ - «да», но моя мотивация, стоящая за этим мнением, ограничена только опытом владения одним-единственным функциональным языком. Тем не менее, это может быть интересно, потому что это чрезвычайно минималистичный язык, таким образом, теоретически очень "чистый" и лежащий в основе многих практических функциональных языков.
Мне было любопытно, насколько легко писать практические программы на таком " чрезвычайно " минималистичный язык функционального программирования, такой как комбинаторная логика .
Конечно, в языках функционального программирования отсутствуют изменяемые переменные, но комбинаторная логика «идет еще дальше», и в ней отсутствуют даже формальные параметры. В нем отсутствует какой-либо синтаксический сахар, отсутствуют какие-либо предопределенные типы данных, даже логические или числа. Все должно быть имитировано комбинаторами и восходит к приложениям всего двух базовых комбинаторов.
Несмотря на такой крайний минимализм, все еще существуют практические методы для «программирования» комбинаторной логики в изящном и приятном виде. путь. Я написал в нем quine в модульном и многоразовом виде, и это не будет неприятно даже для начальной загрузки самоинтерпретатора на нем.
] Вкратце, Я почувствовал следующие особенности использования этого крайне минималистичного функционального языка программирования:
Необходимо изобрести множество вспомогательных функций. В Haskell много синтаксического сахара (сопоставление с образцом, формальные параметры). Вы можете написать довольно сложные функции в несколько строк. Но в комбинаторной логике задача, которая могла бы быть выражена в Haskell одной функцией, должна быть заменена хорошо подобранными вспомогательными функциями. Бремя замены синтаксического сахара в Haskell берут на себя грамотно подобранные вспомогательные функции в комбинаторной логике. Что касается ответа на Ваш первоначальный вопрос: стоит придумать значимые и броские имена для этих легионов вспомогательных функций, потому что они могут быть мощными и многократно используемыми во многих дальнейших контекстах , иногда неожиданным образом .
Более того, программист комбинаторной логики не только вынужден находить броские имена для набора умело выбранных вспомогательных функций, но даже более того, он вынужден (заново) изобретать совершенно новые теории . Например, для имитации списков , программист вынужден имитировать их с помощью их функций складывания , в основном, он должен (заново) изобретать катаморфизмы, концепции глубокой алгебры и теории категорий.
Я предполагаю, что некоторые различия можно проследить до того факта, что функциональные языки имеют мощный «клей» .
В парадигме функционального программирования люди обычно строят абстракции не только сверху вниз , но также снизу вверх . Это означает, что вы в основном улучшаете основной язык. В подобных ситуациях я считаю целесообразным использовать краткие наименования. Язык Haskell уже является кратким и выразительным, так что вы должны привыкнуть к нему.
Однако, пытаясь смоделировать определенную область, я не считаю, что краткие имена хороши, даже когда тела функций маленькие. Знание предметной области должно отражаться в именовании.
Только мое мнение.
В ответ на ваш комментарий
я возьму два фрагмента кода из Real World Haskell , оба из главы 3 .
В разделе « Более контролируемый подход », авторы представляют функцию, которая возвращает второй элемент списка. Их окончательная версия такова:
tidySecond :: [a] -> Maybe a
tidySecond (_:x:_) = Just x
tidySecond _ = Nothing
Функция достаточно универсальна из-за параметра типа a и того факта, что мы действуем со встроенным типом, поэтому нам все равно, что второй элемент на самом деле есть. Я считаю, что x в этом случае достаточно. Точно так же, как в небольшом математическом уравнении.
С другой стороны, в разделе « Введение в локальные переменные » они пишут пример функции, которая пытается смоделировать небольшой фрагмент банковской области :
lend amount balance = let reserve = 100
newBalance = balance - amount
in if balance < reserve
then Nothing
else Just newBalance
Использование здесь короткого имени переменной, конечно, не рекомендуется. Нам действительно важно, что представляют собой эти суммы.
мы действуем на встроенный тип, так что нам все равно, что на самом деле представляет собой второй элемент. Я считаю, что x в этом случае достаточно. Точно так же, как в небольшом математическом уравнении.
С другой стороны, в разделе « Введение в локальные переменные » они пишут пример функции, которая пытается смоделировать небольшой фрагмент банковской области :
lend amount balance = let reserve = 100
newBalance = balance - amount
in if balance < reserve
then Nothing
else Just newBalance
Использование здесь короткого имени переменной, конечно, не рекомендуется. Нам действительно важно, что представляют собой эти суммы.
мы действуем на встроенный тип, так что нам все равно, что на самом деле представляет собой второй элемент. Я считаю, что x в этом случае достаточно. Прямо как в небольшом математическом уравнении.
С другой стороны, в разделе под названием « Введение в локальные переменные » они пишут пример функции, которая пытается смоделировать небольшой фрагмент банковской области :
lend amount balance = let reserve = 100
newBalance = balance - amount
in if balance < reserve
then Nothing
else Just newBalance
Использование здесь короткого имени переменной, конечно, не рекомендуется. Нам действительно важно, что представляют собой эти суммы.
перепишем пример функции, которая пытается смоделировать небольшую часть банковской области:lend amount balance = let reserve = 100
newBalance = balance - amount
in if balance < reserve
then Nothing
else Just newBalance
Использование здесь короткого имени переменной, безусловно, не рекомендуется. Нам действительно важно, что представляют собой эти суммы.
перепишем пример функции, которая пытается смоделировать небольшую часть банковской области:lend amount balance = let reserve = 100
newBalance = balance - amount
in if balance < reserve
then Nothing
else Just newBalance
Использование здесь короткого имени переменной, конечно, не рекомендуется. Нам действительно важно, что представляют собой эти суммы.
Все, что способствует удобочитаемости, - это хорошо - поэтому значащие имена - это хорошо на любом языке.
Я использую короткие имена переменных на многих языках, но они зарезервированы для вещей, которые не являются не важно в общем смысле кода или в том, где смысл ясен в контексте.
Я был бы осторожен, насколько далеко я принял совет насчет имен Haskell
Я думаю, что масштабирование - причина №1 для этого. В императивных языках динамические переменные, особенно глобальные, должны быть названы правильно, поскольку они используются в нескольких функциях. С лексической областью видимости становится ясно, с чем связан символ во время компиляции.
Неизменяемость также в некоторой степени способствует этому - в традиционных языках, таких как C / C ++ / Java, переменная может представлять разные данные в разные моменты времени. Следовательно, ему нужно дать имя, чтобы дать программисту представление о его функциональности.
Лично я считаю, что такие особенности, как функции первого класса, делают имена символов довольно избыточными. В традиционных языках легче соотноситься с символом; по его использованию мы можем сказать, данные это или функция.
Я согласен со многими пунктами, сделанными здесь относительно именования аргументов, но быстрый «поиск на странице» показывает, что никто не упомянул Молчаливое программирование (также известное как бессмысленное / бессмысленное). Будет ли это легче читать, может быть спорным, так что решать вам и вашей команде, но определенно заслуживает тщательного рассмотрения.
Без именованных аргументов = Нет соглашений об именовании аргументов.