vreitech / lvmetabot Goto Github PK

Думаю очевидно, что главное замечание - слишком длинные функции.
В первую очередь - main а во вторую - botProcess.
Сначала про первую.
Кмк, основная причина чрезмерной длины - смешение уровней абстракции, о котором мы говорили.
Т.е., если разложить по пунктам - что именно происходит в главной функции, то получатся такие шаги:

• Прочитать конфигурацию
• Подготовить ботов
• Запустить сервер

В идеале в коде функции main должны быть только вызовы вот этих вот процедур. А сейчас там очень много кода реализации, который уже относится к другому уровню абстракции - не "Что" нужно сделать, а "Как".

Совет 1: Разделить main на несколько четких шагов: Чтение конфига, Инициализация ботов, Запуск сервера. Метод чтения конфига, в свою очередь, можно тоже разделить на логические шаги и вынести их реализацию в отдельные методы: Выбор конфига и собственно чтение. Уведомления об ошибках можно реализовать через исключения.

Тут же, как мне кажется, можно избавиться и от другого примера дурного стиля - глобальной переменной g_globalSettings. Лучше сделай эту структуры возвращаемым значением для метода readConfig. А в botInit можно ее передать параметром.

Совет 2: Глобальные переменные нужно использовать только если совсем нет альтернатив. Передача параметром всегда предпочтительнее.

Тут же встречается довольно частая ошибка - ненужная вложенность условий. Если невыполнение некоего предусловия ведет к выходу из функции, то лучше делать ранний выход, а основной код выполнять уже вне if-а.
Т.е. вместо:

if(условие)
    много ;
    всяких;
    инструкций;
else
    выход;

лучше писать:

if(!условие)
    выход;

много;
всяких;
инструкций;

Совет 3: Лучше избегать чрезмерной вложенности условий. Либо выделяя функции либо используя ранний выход

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

Так же тут вопрос - специально ли объекты client и api создаются в куче, т.е. через new? Ведь они удаляются в конце метода, а значит их можно создать на стеке? Сейчас приходится дублировать очистку объектов во всех точках выхода из функции. Чревато утечками (хотя в D это не так страшно, вроде).

Совет 4: Создание на стеке всегда быстрее, чем в куче, т.к. ему не требуется выделение памяти ОСью. Где возможно стоит создавать объекты именно так.

Так же в этом методе есть и лишняя вложенность, которую можно сократить ранним выходом.
Кстати, если не ошибаюсь, то при невыполнении условия:

if(req.json["message"]["entities"][0]["type"] == "bot_command"
		&& (*g_botNames[botName])["commands"].containsKey(splitCommand[0])
	) {

объекты client и api не удаляются, а значит утекают.

Ну и последнее, что сильно режет глаз - это очень много повторяющихся обращений к контейнеру по одинаковым ключам.
В первую очередь это неэффективно, т.к. каждый раз такое обращение дергает операцию поиска значения по ключу, что не бесплатно. Компилятор может соптимизировать такие места, но это нужно проверять. Плюс, такие повторения - это, как правило, копипаст. А копипаст всегда плох, т.к. может приводить к сложно находимым опечаткам.

*Совет 5: Стоит избегать копипаста где это только возможно. Это упрощает последующие изменения и сокращает риск ошибок по невнимательности.

Т.е. общие части, вроде (*g_botNames[botName])["commands"][splitCommand[0]]["permissionChatIdMapping"] всегда лучше записывать в переменные (можно по ссылке). Это и улучшит читаемость (если правильное имя переменной дать) и потенциально немного ускорит работу.