Замечания по коду

[KateBushueva]

модуль Common.Functions

template :: String -> [String] -> String
template str args = foldl f str $ zip ts args
  where
    ts = map (\n -> ('{' : show n) ++ "}") [0 :: Int, 1 ..]
    f :: String -> (String, String) -> String
    f acc (t, arg) = replace t arg acc
    replace :: String -> String -> String -> String
    replace t0 s str0 =
      let strs = splitOn t0 str0
       in concat $ init $ foldr (\part acc0 -> part : s : acc0) [] strs

• непонятные названия переменных, можно увеличить читабельность функции введя понятные наименования
• использование небезопасных функций (init) без проверки

  checkUnique :: Eq a => [a] -> Bool
  checkUnique l = let newList = filter (== True) ((==) <$> l <*> l) in length newList == length l

  очень нерациональная проверка на уникальность

[KateBushueva]

модуль Transformer.Internal исключения в IO монаде бросаются через throwIO

[KateBushueva]

модуль Logic.App комментарии, которые дублируют код, не нужны в остальном по читабельности этот модуль мне нравится

[KateBushueva]

модуль Logic.Logic

• убрать закомменченный импорт
• в функции toMessageCommand постараться избавиться от вложенный кейсов

[KateBushueva]

модуль Messenger.Bot.Class я бы сделала проще, без TypeFamilies. Но не против оставить как есть. Здесь необходимо убрать закомменченный код

[pf03]

модуль 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. Там список из двух имен ботов проверяется, это вообще не критично

[pf03]

модуль Transformer.Internal исключения в IO монаде бросаются через throwIO

исправил. Ошибки в чистом коде бросаются в Either. Ошибки в монаде IO - throwIO Ошибки в монаде Transformer - liftIO . throwIO

[pf03]

модуль Logic.App комментарии, которые дублируют код, не нужны в остальном по читабельности этот модуль мне нравится

исправил

[pf03]

модуль Logic.Logic

• убрать закомменченный импорт
• в функции toMessageCommand постараться избавиться от вложенный кейсов

исправил, хотя 2 уровня вложенности допускается, как указано в риззоме

[pf03]

модуль Messenger.Bot.Class я бы сделала проще, без TypeFamilies. Но не против оставить как есть.

Я сделал синтаксис по образцу Алексея

Здесь необходимо убрать закомменченный код

исправил

[KateBushueva]

модуль Interface.Cache.Config.State

• функции getStateFromConfig и getStatesFromConfig : можно ли уменьшить количество дублирования кода?
• функция getStateFromConfig : используешь небезопасную функцию head . В таких случаях удобно пользоваться listToMaybe из Data.Maybe
• функция saveState : в данном контексте Error.liftEIO ведет себя не совсем корректно. Нужно будет исправить имплементацию Error.liftEIO - напишу подробно, когда буду прописывать модуль Interface.Error.Functions

[KateBushueva]

модуль Interface.Error.Functions

• функция liftEIO работает с MonadIO m и кидать ошибку она должна специализированную для ИО монады throwIO . В коде же вызывается функция liftE у которой контекст просто Monad m и поднятие ошибки происходит через обычный throw. Та же история с catchEIO. В принципе, функция liftE вызывается только из этих двух функций, так что кмк можно просто исправить в ней throw на throwIO (ну и поменять контекст)
• функция try : в модуле Control.Exception есть функция catches которая в качестве второго аргумента принимает список хэндлеров, нет необходимости вызывать catch для каждого хэндлера

[KateBushueva]

модуль Interface.Log.Class ?

[KateBushueva]

модуль Interface.Log.Functions

• зачем там расширение FlexibleContexts?
• функция resetSettings нигде не используется
• функция withLogM не используется
• функция writeToFile : предполагаю, что appendFile может кидать исключения

[KateBushueva]

модуль Interface.Log.Types не нужно оставлять комментарии, которые дублируют код

[KateBushueva]

модуль Interface.MTrans ?

[KateBushueva]

модуль Logic.VK.Query.Functions функция sendMessageQuery : странно с точки зрения восприятия использование Either монады, где у тебя левый конструктор приводит к корректному выполнению функции, а правый конструктор приводит к ошибке.

[KateBushueva]

модуль Messenger.Bot.Telegram.Instances

• убрать ненужные расширения
• указать явно импортируемые сущности (или сделать квалифицированные импорты)

аналогично в модуле Messenger.Bot.VK.Instances

[KateBushueva]

модули Messenger.Bot.VK.Types и Messenger.Bot.Telegram.Types убрать ненужные расширения

[KateBushueva]

модуль Common.Types

• убрать лишние расширения
• что такое StrId и IntId? думаю, надо дать более понятные имена, отражающие суть, а не тип этих сущностей

[KateBushueva]

модули Messenger.Update.Telegram.Types и Messenger.Update.VK.Types

• убрать лишние расширения

[KateBushueva]

Кстати, по поводу расширений: ты можешь прописать необходимые в package.yaml файле (как это у тебя сделано с OverloadedStrings). В таком случае не будет необходимости прописывать их в каждом файле, где требуется

[KateBushueva]

модуль Parse.Telegram.Functions

• убрать расширение OverloadedStrings - оно у прописано в .yaml файле

[KateBushueva]

модуль Parse.Telegram.Internal

• убрать OverloadedStrings
• полезный комментарий в этом модуле - на 33 строке, остальные можно смело убирать. Некоторые комменты вызывают больше вопросов, чем ответов, например, на 58 строке (все знают, как работает оператор альтернативы..)
• вложенные кейсы, которые в случае Мэйби можно заменить функцией maybe

[KateBushueva]

Все, с моей стороны больше претензий к боту нет

[pf03]

модуль 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)

А уже в выходной переменной идет контекст обработки ошибок.

[KateBushueva]

Я говорю с концептуальной точки зрения: монада Either предполагает левый конструктор как ошибку - такое восприятие, так будет отрабатывать монадический байнд. На проекте я бы оставила таску сделать подходящий тип-сумму или иным образом обрабатывать, но не использовать монаду Either не в своем предназначении

[pf03]

Я говорю с концептуальной точки зрения: монада Either предполагает левый конструктор как ошибку - такое восприятие, так будет отрабатывать монадический байнд. На проекте я бы оставила таску сделать подходящий тип-сумму или иным образом обрабатывать, но не использовать монаду Either не в своем предназначении

исправил на сумму типов

[pf03]

исправил по всем пунктам