Closed KateBushueva closed 3 years ago
модуль Transformer.Internal
исключения в IO монаде бросаются через throwIO
модуль Logic.App
комментарии, которые дублируют код, не нужны
в остальном по читабельности этот модуль мне нравится
модуль Logic.Logic
toMessageCommand
постараться избавиться от вложенный кейсовмодуль Messenger.Bot.Class
я бы сделала проще, без TypeFamilies
. Но не против оставить как есть.
Здесь необходимо убрать закомменченный код
модуль
Common.Functions
template :: String -> [String] -> String
- непонятные названия переменных, можно увеличить читабельность функции введя понятные наименования
- использование небезопасных функций (init) без проверки
исправил
checkUnique :: Eq a => [a] -> Bool checkUnique l = let newList = filter (== True) ((==) <$> l <*> l) in length newList == length l
очень нерациональная проверка на уникальность
Исправил через сортировку, сложность n*log n вместо n^2. Там список из двух имен ботов проверяется, это вообще не критично
модуль
Transformer.Internal
исключения в IO монаде бросаются черезthrowIO
исправил.
Ошибки в чистом коде бросаются в Either
.
Ошибки в монаде IO
- throwIO
Ошибки в монаде Transformer
- liftIO . throwIO
модуль
Logic.App
комментарии, которые дублируют код, не нужны в остальном по читабельности этот модуль мне нравится
исправил
модуль
Logic.Logic
- убрать закомменченный импорт
- в функции
toMessageCommand
постараться избавиться от вложенный кейсов
исправил, хотя 2 уровня вложенности допускается, как указано в риззоме
модуль
Messenger.Bot.Class
я бы сделала проще, безTypeFamilies
. Но не против оставить как есть.
Я сделал синтаксис по образцу Алексея
Здесь необходимо убрать закомменченный код
исправил
модуль Interface.Cache.Config.State
getStateFromConfig
и getStatesFromConfig
: можно ли уменьшить количество дублирования кода?getStateFromConfig
: используешь небезопасную функцию head
. В таких случаях удобно пользоваться listToMaybe
из Data.Maybe
saveState
: в данном контексте Error.liftEIO
ведет себя не совсем корректно. Нужно будет исправить имплементацию Error.liftEIO
- напишу подробно, когда буду прописывать модуль Interface.Error.Functions
модуль Interface.Error.Functions
liftEIO
работает с MonadIO m
и кидать ошибку она должна специализированную для ИО монады throwIO
. В коде же вызывается функция liftE
у которой контекст просто Monad m
и поднятие ошибки происходит через обычный throw
. Та же история с catchEIO
. В принципе, функция liftE
вызывается только из этих двух функций, так что кмк можно просто исправить в ней throw
на throwIO
(ну и поменять контекст)try
: в модуле Control.Exception
есть функция catches
которая в качестве второго аргумента принимает список хэндлеров, нет необходимости вызывать catch
для каждого хэндлерамодуль Interface.Log.Class
?
модуль Interface.Log.Functions
FlexibleContexts
?resetSettings
нигде не используетсяwithLogM
не используетсяwriteToFile
: предполагаю, что appendFile
может кидать исключениямодуль Interface.Log.Types
не нужно оставлять комментарии, которые дублируют код
модуль Interface.MTrans
?
модуль Logic.VK.Query.Functions
функция sendMessageQuery
: странно с точки зрения восприятия использование Either монады, где у тебя левый конструктор приводит к корректному выполнению функции, а правый конструктор приводит к ошибке.
модуль Messenger.Bot.Telegram.Instances
аналогично в модуле Messenger.Bot.VK.Instances
модули Messenger.Bot.VK.Types
и Messenger.Bot.Telegram.Types
убрать ненужные расширения
модуль Common.Types
StrId
и IntId
? думаю, надо дать более понятные имена, отражающие суть, а не тип этих сущностеймодули Messenger.Update.Telegram.Types
и Messenger.Update.VK.Types
Кстати, по поводу расширений: ты можешь прописать необходимые в package.yaml
файле (как это у тебя сделано с OverloadedStrings
). В таком случае не будет необходимости прописывать их в каждом файле, где требуется
модуль Parse.Telegram.Functions
OverloadedStrings
- оно у прописано в .yaml файлемодуль Parse.Telegram.Internal
OverloadedStrings
maybe
Все, с моей стороны больше претензий к боту нет
модуль
Logic.VK.Query.Functions
функцияsendMessageQuery
: странно с точки зрения восприятия использование Either монады, где у тебя левый конструктор приводит к корректному выполнению функции, а правый конструктор приводит к ошибке.
в переменной eMessageCommand
монада Either
используется в контексте "сообщение или команда" а не для обработки ошибок. Такая структура Update.Update
прописана в Messenger.Update.VK.Types
type Update = (ChatId, Entity) data Entity = Entity {body :: Either Message Command, attachments :: [Attachment]} deriving (Show)
А уже в выходной переменной идет контекст обработки ошибок.
Я говорю с концептуальной точки зрения: монада Either
предполагает левый конструктор как ошибку - такое восприятие, так будет отрабатывать монадический байнд. На проекте я бы оставила таску сделать подходящий тип-сумму или иным образом обрабатывать, но не использовать монаду Either
не в своем предназначении
Я говорю с концептуальной точки зрения: монада
Either
предполагает левый конструктор как ошибку - такое восприятие, так будет отрабатывать монадический байнд. На проекте я бы оставила таску сделать подходящий тип-сумму или иным образом обрабатывать, но не использовать монадуEither
не в своем предназначении
исправил на сумму типов
исправил по всем пунктам
модуль
Common.Functions
очень нерациональная проверка на уникальность