Ай как нехорошо писать плагины ИИшкой от начала и до конца без перепроверки
Так могла сделать только иишка:
Авторизуйтесь для просмотра ссылок.
Почему?
Она всегда считает, что всё, что содержит в себе какой бы то ни было асинхрон требует конкурентных мап, даже когда они неуместны, как при чат ивенте. Чат ивент происходит всегда в ОДНОМ потоке для конкретного игрока (либо каждый раз в новом для leaf по умолчанию, но это не суть)
Важно тут то, что использование в данном случае конкурентной мапы излишне.
При чтении мапы и отсутствии иных действий с ней никаких ошибок не будет, следовательно тратить ресурсы на излишнюю синхронизацию смысла не имеет.
Аналогичный ИИ слоп:
Авторизуйтесь для просмотра ссылок.
Авторизуйтесь для просмотра ссылок.
Почему?
ИИ не знает, как работает майнкрафт на низком уровне, а человек бы банально не сделал подобного. Игрок чисто физически не может отправить пакет чата, который имел бы в себе пустую строку, а ивент не может вернуть null в message
Авторизуйтесь для просмотра ссылок.
, оно не зря отмечено как NotNull.
(Аналогично с PlayerCommandPreprocessEvent, логика схожа)
И самый ОЧЕВИДНЫЙ след ИИшки:
Авторизуйтесь для просмотра ссылок.
Авторизуйтесь для просмотра ссылок.
Авторизуйтесь для просмотра ссылок.
Авторизуйтесь для просмотра ссылок.
Так могла сделать ИСКЛЮЧИТЕЛЬНО ии модель, поскольку ни один человек не станет указывать класс с пакетами вместо импорта, если на то нет очевидной причины (дубликата импорта с идентичным именем класса, заметно при работе с NMS), но даже в такой ситуации в данном конкретном случае любой человек предпочёл бы данному некрасивому импорту использование
var
Помимо того можно прикопаться к данным моментам:
1)
Авторизуйтесь для просмотра ссылок.
А именно !word.trim().isEmpty()
Такое необходимо отсекать на моменте в ConfigManager, чтобы пустые элементы не записывались в лист или сет в принципе, точно сказать ИИ это или нет нельзя, но всё же момент занятный.
2)
Авторизуйтесь для просмотра ссылок.
Я не вижу причин, чтобы делать так. ИИ любят создавать копии листов без причин, просто для абстрактной "безопасности", игнорируя логику. Но всё же это конечно не факт, что ИИ.
3) Следим за руками
Авторизуйтесь для просмотра ссылок.
Авторизуйтесь для просмотра ссылок.
Авторизуйтесь для просмотра ссылок.
3 места, где используется plugin.getServer()
Но вот тут:
Авторизуйтесь для просмотра ссылок.
Используется просто Bukkit.
plugin.getServer().yourStuff по сути идентичен Bukkit.yourStuff, а потому не ясно непостоянство.
getServer я могу предпочесть в JavaPlugin, где использовать геттер для сервера вместо статик методов бакита просто, но в ином случае это как будто не имеет никакого смысла...
Кроме того:
1) Не ясно в чём отличия bad-words от blocked-words?
Конфиги идентичны за исключением разве что опции detect-english-lookalikes:
Ошибка на этапе производства? Забыл что сделал и сделал повторно?
2) Не ясно ради чего использовать LinkedHashMap в данном случае
Авторизуйтесь для просмотра ссылок.
Ради чего ИИ запихнул сюда ЛИНКЕД мапу? Нигде не требуется, чтобы элементы были в чётком порядке...
Видимо ИИшке просто захотелось абстрактной безопасности, уж слишком сильно ей это вдолбили в голову, а вот логику базовую ей увы не вдолбили
(Отмазываться от того, что ВЕСЬ код в данном классе сделан ИИшкой бессмысленно, поскольку импорты всё ещё существуют
Авторизуйтесь для просмотра ссылок.
Авторизуйтесь для просмотра ссылок.
)
3) Само существование класса
Авторизуйтесь для просмотра ссылок.
Мне не понять...
Зачем делать Class.forName, если можно сразу взять placeholderAPIAvailable = Bukkit.getPluginManager().getPlugin("PlaceholderAPI") != null; обойдясь без лишнего кода?..
4) Мелкая придирка, но формирование паттерна в рантайме дико неэффективно
Авторизуйтесь для просмотра ссылок.
(как и сами паттерны... но программисты обленились, а после этого обленились и ИИшки, которые на них обучались)
Так что делаем выводы господа
