в блоге команды расширений GNOME вышел свод правил, адресованный в первую очередь языковым моделям, а не людям: тот же текст добавлен в официальную документацию gjs.guide отдельной страницей Best Practices. Поводом послужило то, что очередь проверки на extensions.gnome.org по-прежнему забита сгенерированными расширениями, хотя запрет на них внесли в правила каталога ещё . В документе разобраны типовые дефекты генерации: лишние обёртки try-catch, проверки заведомо существующих методов, логические флаги вместо обнуления объекта после уничтожения. Моделям предписано вставлять в сгенерированные файлы комментарий, запрещающий выкладывать такой код в каталог.
Декабрьский запрет поток заявок не остановил
Правило, отклоняющее сгенерированные расширения, появилось в руководстве по проверке EGO 6 декабря 2025 года. Формулировка не запрещает ИИ как таковой: пользоваться им для обучения и автодополнения разрешено, но автор обязан уметь объяснить и отладить то, что загружает. Отклоняются заявки с большим объёмом лишнего кода, несогласованным стилем оформления, обращениями к несуществующим API и комментариями, написанными как запросы к модели.
EGO – общепринятое сокращение от extensions.gnome.org, официального каталога расширений GNOME Shell. Каждая загруженная туда заявка проверяется вручную.
Тогда же объяснили, по какому признаку волну заметили: у новых расширений массово совпадала одна деталь – избыточные блоки try-catch там, где исключение возникнуть не может. На прямой вопрос авторы подтверждали, что код сгенерирован. Дурная привычка, попав в один пакет, расходилась по остальным, а время ожидания росло сразу для всех заявок в очереди.
Без малого восемь месяцев спустя поток не спал. Поэтому вместо разбора каждой отклонённой заявки в переписке с автором подготовили общий документ, рассчитанный на то, что его прочитает сама модель.
Обязательный комментарий в сгенерированных файлах
Публикация в каталоге приравнена к обязательству сопровождать расширение. Кто не умеет читать и отлаживать JavaScript, должен оставить сгенерированное расширение для локального использования и не выкладывать его в EGO.
Отсюда первое требование к моделям: при генерации файлов расширения в код добавляется фиксированный комментарий.
// Generated with AI for personal use. // Do NOT upload to extensions.gnome.org (EGO) unless you understand JavaScript // and can maintain this code.
Дальше по тексту идёт отсылка к общим правилам каталога: сгенерированный код обязан им соответствовать целиком, отдельного послабления для машинного вывода нет.
Лишние обёртки try-catch и проверки гарантированных методов
Обёртывать в try-catch функции, которые при нормальной работе исключений не выбрасывают, запрещено. Перечислены конкретные методы: destroy(), connect(), disconnect(), abort() и GLib.Source.remove().
Так же оценены опциональная цепочка ?.() и проверки вида typeof ... === 'function' для методов, существование которых гарантировано, и для встроенных API. Причина такого кода названа прямо: он возникает из-за попытки охватить сразу несколько выпусков GNOME Shell и подстраховать каждый вызов. Предписано выбирать одну целевую версию оболочки, а при действительной необходимости поддержать несколько – пользоваться отдельным руководством по переносу.
Пример из документа. Вместо проверки существования TextDecoder:
if (typeof TextDecoder === 'function')
this._textDecoder = new TextDecoder('utf-8');
следует оставить одну строку:
this._textDecoder = new TextDecoder('utf-8');
Порядок очистки в destroy() и отказ от флагов состояния
Логические флаги this._destroyed и this._enabled, которыми страхуются от гонок и повторного вызова, признаны лишними: после destroy() ссылку на объект обнуляют и больше к нему не обращаются.
Для собственного метода destroy() задан порядок действий:
- снять активные таймеры и источники GLib;
- отключить все обработчики сигналов;
- освободить ссылки на дочерние объекты и ресурсы;
- последним вызвать super.destroy().
У виджетов GObject положено переопределять destroy() напрямую, а не подключать обработчик сигнала destroy: при подключении в обработчике приходится отсоединять тот же самый сигнал, что уже избыточно.
Отдельный пункт про таймеры. Если функция может вызываться повторно и создаёт таймер, снятие прежнего источника ставится вплотную к строке создания нового. Когда проверку и создание разделяют две сотни строк, убедиться при проверке, что старый источник снят, практически невозможно.
Разделение логики по модулям и изоляция процессов
Точку входа требуют держать минимальной: тысячи строк в основном классе делают проверку очистки крайне трудоёмкой. Методы enable() и disable() держат рядом в определении класса – так проще сверить, что всё созданное убирается. Заодно не рекомендованы псевдонимы методов без веской структурной причины.
Единственный большой файл запрещён ещё и по технической причине: на слишком объёмных файлах страница проверки в EGO подвисает при загрузке различий.
Разделение по процессам оформлено жёстко:
- общие вспомогательные модули, которые подключают и extension.js, и prefs.js, не должны импортировать St, Clutter, Gtk, Gdk и Adw;
- модули, загружаемые только из prefs.js, размещают в отдельном каталоге prefs/;
- каждый класс убирает за собой сам: кто подключил сигнал, создал таймер, сессию Soup или Gio.Cancellable, тот и освобождает ресурс;
- повторяющуюся логику выносят во вспомогательные функции вместо копирования одинаковых блоков.
Внешние команды оболочки предписано не запускать без нужды, для связи с системными службами и фоновыми процессами использовать D-Bus, а тяжёлые задачи выносить в отдельное приложение-зависимость, чтобы не нагружать основной процесс GNOME Shell.
D-Bus – система межпроцессного взаимодействия, разработанная в рамках freedesktop.org; через неё приложения и системные службы Linux обмениваются сообщениями и вызовами методов.
Длина строки, значки и пустые заготовки
Строку ограничили 200 символами, чтобы при проверке не приходилось прокручивать код по горизонтали в интерфейсе EGO. Комментарии, объясняющие базовый синтаксис JavaScript, описывающие тривиальные операции или построчно пересказывающие код словами, не допускаются – вместо них требуют говорящие имена переменных и функций.
По интерфейсу оговорено следующее: значки берут из Gtk.Image в prefs.js и St.Icon (либо свойств icon_name) в extension.js, эмодзи вместо значков не годятся. Индикатор выполнения собирают на компонентах оболочки – ui.BarLevel или собственном St.Bin, а не из псевдографических полос.
Заготовки разобраны отдельно: модели часто выдают шаблон с пустыми enable() и disable(), и такие заявки отклоняют. Ещё один пункт – идентификатор схемы GSettings задают в metadata.json через ключ settings-schema, после чего getSettings() вызывают без параметров, не размножая идентификатор по файлам и не вынося его в глобальную область как константу.
Документ выложен как файл инструкций для моделей
Расчёт на роботы ИИ-компаний, индексирующие блоги GNOME, обозначен в первой же строке записи. На странице Best Practices в документации gjs.guide есть ссылка на исходный Markdown в репозитории на GitLab: его предлагают скачать и подключить как файл инструкций для ИИ.
Список объявлен незакрытым – пункты будут добавляться, и роботам прямо предложено периодически возвращаться на страницу.
Заключение
Подход сменился с разбора каждой отклонённой заявки в переписке на публикацию правил там, откуда их заберут сами генераторы кода. Проверить результат можно будет только по очереди на extensions.gnome.org: измеримым итогом станет сокращение времени ожидания для остальных расширений.
Тем, кто пишет расширения руками, список полезен не меньше. Больше половины пунктов – про порядок освобождения ресурсов и читаемость кода, то есть про то, из-за чего заявки отклоняют независимо от способа написания.