Публикации ›
Результаты ревью кода 1500+ решений каталога Инфостарт: наиболее частые ошибки разработчиков в коде ›
#47
11.04.24 16:38
Привет, Артур, спасибо за статью и выступление, очень интересно.
BSL LS отличная штука, сам периодически пользуюсь ( (раньше часто использовал phoenix bsl, где нужно просто проанализировать текущий код)), и тем самым повышая свой уровень кода, всего не упомнишь, и без проверки можно многое упустить при разработке. Главное такие знания вспоминать и применять на практике, а то все со временем забывается. Но некоторые проверки отключаю, например, проверка на устаревшие функции, или проверка
чтобы строковые литералы обязательно были помещены в конструкцию НСТр.
Не хочу быть "адвокатом дьявола", но не все так категорично:
По поводу "глухой попытки" - когда-то ранее в типовых наличие свойства у объекта проверяли через попытку: обратились к свойству, если исключение, то значит свойства нет, чуть позже пришли к созданию структуры со свойством, и через ЗаполнитьЗначениеСвойство() проверяют если свойство заполнено, то значит оно есть у объекта, довольно оригинально. Да и в принципе помню есть ряд моментов, что исключение это лишь повод
использовать другой способ обработки данных, и его необязательно куда-то записывать и вызывать, либо исключение оказывается гораздо быстрее, что проверка на валидацию данных.
Про открытие XML по интернету: Использование недокументированных возможностей - это зло. Хотя помню как передавали таблицу значений с сервера на клиент через метод сообщить, и потом преобразовывали ее из ЗначениеИзСтрокиВнутр():)
Отмечу также, что ряд проверок не учитывают ни версию БСП, ни версию платформы, ни конфигурацию, для которой разрабатывается решение. То есть у нас всегда должна быть актуальная платформа, и желательно ERP, но не все так радужно для разработчика какого-нибудь собственного решения.
Если у тебя не жесткая зависимость одна конфигурация определенной версии - одно решение, то тебе уже приходится как-то извращаться, чтобы твое решение работало и на Бухгалтерии актуального релиза, и на какой-нибудь допотопной УНФ, или вообще на обычных формах. В такие моменты начинаешь ценить, что в синтакс-помощнике есть информация, с какой именно версии платформы появилась функциональность, те же самые таймауты на http соединение тоже появились не сразу, плюс некоторые функциональности работают по-разному в разных режимах совместимости платформы.
Или вот рекомендация по поводу использования ДополнительныеОтчетыИОбработки.СведенияОВнешнейОбработке(). Разработчики не от хорошей жизни использовали по началу такую конструкцию, ведь в БСП по факту не было подобного варианта реализации, не было готовой структуры, которую можно вызывать, так и приучились. А кто хочет переучиваться, если итак все работает? Отсюда выходит, что проблема не от того, что не хочешь писать красивый код, а слишком много знаешь, и повидал такого в типовых, что волосы дыбом.
Ну и как правильно отметили в комментариях, что тут еще стоит вопрос времени и денег. За чей счет банкет? Поддержание кода с учетом стандартов разработки, это не самая простая задача, и разработчику, а особенно неопытному разработчику, который и совершает подобные ошибки, получив такое уведомление попросту не будет ничего размещать. А более опытный оценит, а стоит ли это моих усилий, для решения, которое даже не приносит денег. В общем это отсеит я думаю процентов 90 желающих.
Также отмечу по поводу размещения и анализа кода собственного решения, в такой реализации получается не сделать ни собственной системы лицензирования, ни закрыть код, который не хочешь иметь в свободном доступе.
Кстати, "функции, которые являются процедурами – зачем-то их делают функциями" - это делается для того, чтобы можно было вызывать их при отладке через "ВычислитьВыражение" :)
