SonarQube 1C (BSL) - Выпуск релиза 1.3

#1

1.3.0

Исправлены проверки:

  • В проверке “Экспортные процедуры/функции/переменные должны содержать описание” убрано ложное срабатывание, когда перед определением процедуры находилась инструкция препроцессору
  • В проверке “Прямое указание GUID в коде” убрано ложное срабатывание на пустом GUID

Добавлены проверки:

  • В начале процедуры обработки регламентного задания отсутствует вызов метода “ОбщегоНазначения.ПриНачалеВыполненияРегламентногоЗадания();”.
  • Запрет на использования конструкции “ПЕРВЫЕ” совместно с конструкцией “АВТОУПОРЯДОЧИВАНИЕ”
  • Ограничение на выполнение «внешнего» кода на сервере
  • Ограничение на использование конструкции “АВТОУПОРЯДОЧИВАНИЕ”
  • Совместное использование “УПОРЯДОЧИТЬ ПО” с конструкцией “РАЗЛИЧНЫЕ”
  • Функция должна возвращать значение

Изменения правил грамматики:

Язык запросов:

  • Добавлено правило грамматической конструкции “УНИЧТОЖИТЬ”
  • Добавлено правило грамматической конструкции “ИМЕЮЩИЕ”
  • Добавлена обработка пустого пакета

Прочее:

  • Добавлена обработка метаданных конфигурации в формате XML
  • Обеспечена работа с SonarQube 6.3
2 Симпатий
#2

@nixel2007, а что подразумевается под “Добавлена обработка метаданных конфигурации в формате XML”?

#3

Теперь в AST дереве доступна возможность анализировать метаданные, но не для Graphite

Фишка в том что метаданные

  • в 1С формате - это XML с расширением XML
  • в EDT формате - это XML c расширением MDO
#4

Вот эта проверка модуля построена уже на основе контекста метаданного из XML

#5

Да, @lustin верно написал. Плагин теперь строит кэш по объектам метаданных, и эти данные доступны из проверок.

#6

Только для зашитых проверок? Как-то меняется теперь само дерево? Я так понял, теперь плагин оба формата обрабатывает как-то сообща, получая взаимосвязанные данные для проверки?
Влияет это на:

  • то если будет подключен еще плагин для xml отдельный?
  • скорость проверки?
#7

да, эта информация доступна только из java-кода.

нет, дерево осталось без изменения.

Сначала строится кэш метаданных, потом запускаются java-проверки. Сами проверки метаданных ничем не отличаются от обычных проверок - просто в одних используется кэш метаданных, а в других нет.

С плагином XML нет явных пересечений – bsl-плагин вычитывает данные из XML независимо от XML-плагина. На данный момент XML-файлы не отправляются на сервер SQ и могут быть так же заигнорены в sonar-project.properties. Скорость, конечно, снизилась (за счет чтения дополнительных файлов и построения кэша), но незначительно. Мы решили добавлять новые типы объектов в кэш по мере необходимости - т.к. сейчас требовались только данные регл. заданий и общих модулей, то и кэш метаданных строится только по ним. Но повторюсь, это крайне малая доля во времени работы анализа.

#8

А это отключаемый механизм?

#9

на данный момент нет. Да и не планировалось в целом.
Кэш метаданных так же будет нужен для построения проверок, опирающихся на контекст модулей. А всякие глобальные переменные и реквизиты формы/объекта можно отловить только используя метаданные.

#10

А как действовать при обновлении плагина, если время его работы после обновления станет неприемлемым или будут появляться ошибки, связанные с кешем метаданных? Откатывать плагин на предыдущую версию? Сонар в бою может поддерживать несколько проектов и нужно это учитывать.

#11

[quote=“dunar, post:10, topic:821, full:true”]
А как действовать при обновлении плагина, если время его работы после обновления станет неприемлемым [/quote]

Мы запускали несколько прогонов ERP 2.2/Бух корп/ЗУП Корп, замедления работы не заметили вообще - все в рамках погрешностей.
Эта операция занимает доли процента от обычного времени анализа.

будут появляться ошибки, связанные с кешем метаданных

Абсолютно все проверки и блоки плагина покрыты тестами. Общее покрытие кода тестами превышает 90 процентов. Мы тщательно следим за регрессией и стараемся не допускать новых ошибок в принципе. Если Вы обнаружите какую-то ошибку в работе любого механизма - фиксируйте баг-репорт, будем исправлять. Рассматриваем так же оперативные варианты выпуска критичных баг-фиксов вне обычного “длинного” цикла разработки.

1 Симпатия
#12

В крайнем случае - да, можно сделать откат. Мы не меняем структуру БД, поэтому откат пройдет максимально безболезненно - просто выключатся добавленные в новом релизе проверки.

#13

Добрый день!

Как вы смотрите на такую проверку?
Вместо конструкций вида

ПропускатьПустыеСтроки = ?(Разделитель = Пробел, Истина, Ложь);

или

Если Разделитель = Пробел Тогда
ПропускатьПустыеСтроки = Истина;
Иначе
ПропускатьПустыеСтроки = Ложь;
КонецЕсли;

использовать выражение

ПропускатьПустыеСтроки = (Разделитель = Пробел);

1 Симпатия
#14

Также хотел уточнить, у вас есть в планах обрабатывать запросы динамических списков (он “запакован” в xml-файл формы) и запросы компоновок?

#15

Интересное предложение, перенес к нам на доску :slight_smile:

#16

еще интереснее!
В планах не было, но добавим, благо вытащить легко

1 Симпатия
#17

P[quote=“dunar, post:13, topic:821, full:true”]
ПропускатьПустыеСтроки = (Разделитель = Пробел);
[/quote]

Я бы не делал его “включаемым” по умолчанию, так как это многим 1С специалистам будет не понятно и выглядеть как магия. Мне кажется не многие знают что (Истина = Ложь) это вообще-то выражение :wink:

#18

Извините, не могу удержаться, когда вижу такое:

ПропускатьПустыеСтроки = ?(Разделитель = Пробел, Истина, Ложь);

или такое

Если Разделитель = Пробел Тогда
ПропускатьПустыеСтроки = Истина;
Иначе
ПропускатьПустыеСтроки = Ложь;
КонецЕсли;

или такое

ПропускатьПустыеСтроки = (Разделитель = Пробел);

Вот такое выражение даёт +100 очков к наглядности:

ПропускатьПустыеСтроки = ПропускатьПустыеСтроки();

Функция ПропускатьПустыеСтроки()
    Возврат Разделитель = Пробел;
КонецФункции
2 Симпатий
#19

Ну а разве учить разработчиков не одна из целей такого механизма?
Включено оно или нет - думаю вопрос проекта, пусть по умолчанию будет выключенным

#20

Хочу релиз 1.6… ну хотябы 1.4 :slight_smile:

1 Симпатия