SonarQube.Излишнее разыменование полей

sonar-bsl-plugin

#1

Сонар реагирует предупреждением на такую строку запроса
“ПланЗагрузкиКПП.ЗаданиеНаПеревозку.СпособДоставки КАК СпособДоставки,”
следующим замечанием
“Излишнее разыменование полей в строке:”
со следующими комментариями
“Использование более N точек в запросе может привести к понижению производительности.”
Да разыменование, ведет к неявному соединению с таблицами, но ведь это повышает читаемость запроса. ЗаданиеНаПеревозку - это не составной тип и я не хочу явно прописывать соединения с другими таблицами, тем более что стандартами 1С это не ограничивается?


#2

Не забываем, что неугодные правила всегда можно отключить.


#3

… или понизить важность


#4

Правило отключать НЕ нужно. Обычно достаточно отключить какое-то замечание. в конкретном месте кода, под своим пользователем. Если вы с ЗАМЕЧАНИЕМ не согласны. Вы праве это делать :wink:


#5

неугодные правила - это не правила. :wink:


#6

Это решает тим-лид


#7

Извини Никит - но нет. Тим-лид не отключает правила. Правила как мы помним включаются в ПрофильКачества, а профиль качества правильно делать единым на компанию. То есть это зона ответственности Руководителя всей разработки по конкретному языку. То есть руководителя центра компетенции по 1С.

Тим-лид может ходотайствовать о чем то, но только и всего.В остальных случаях он идет далеко со своими попытками внести хаос в стройное понимание качества внутри компании.

Если руководитель центра компетенции (руководитель отдела разработки) настолько разгильдяй что спустил данную ситуацию до тимлидов - он просто не в курсе чем ему это грозит. Но это вопрос его компетенции.

P.S. @nixel2007 @theshadowco - я знаю что вы обладаете огромным багажом практических знаний, но пожалуйста не вводите в ступор юных пользователей в части методологии. Практическое применение правил и профиля качества это одно, а методическое это другое. Истина посредине как обычно, пожалуйста добавляйте при ответе, что это ВЫ так делаете (отключаете правило), хотя методически это НЕ верно.


#8

В мелких компаниях часто тим лид = руководитель отдела. Но ты прав, я имел ввиду рукля.


#9

Если отключение идёт на всю компанию, то это не НЕ верно.


#10

почему профиль качества по одному языку правильно делать единым на компанию, а не индивидуально в зависимости от соглашений по отдельному проекту (продукту)?

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


#11

Лёша апеллирует к основам концепции Continuous Inspection, представленной головными SonarSource. Один из принципов - единые стандарты качества для всех продуктов


#12

Не Лёша, а Алексей Александрович. Попрошу не извращать мои слова - я ни к чему не апеллировал. Если бы апеллировал - указал бы ссылку.

И в этой теме повторюсь - @nixel2007 выбирай выражения и сохраняй пожалуйста корректность, ведешь себя последнее время как тролль какой-то.


#13

Не помню, чтобы ратовал за отключение правил.
А так, могу поделиться правилами, по которым то или иное правило активизиуется или нет:

  • используется разный набор правил для версий платформ, ибо бессмысленно мучить коллег требованиями например не использовать устаревший метод “Найти”
  • используется разный набор правил для решений с разным назначением: для библиотечных (базовых) конфигураций и расширений используются более жесткие правила, чем для конечных прикладных решений (в том числе более жестко, чем предлагают разработчики правил)
  • снижается приоритет правил, которые надо учитывать, но пока не доросли :frowning:
  • отключаются правила, которые не имеют никакого значения в нашей разработке (например правило требующее вызова спец метода у регламентных заданий)

#14

И это касается не только 1С, с java / c# / sql / ps / с++ аналогично


#15

В шапке просто вопрос задавался, про конкретное срабатывание. Я поэтому отрефлексировал на предложение отключить правило.

ДА ты прав конечно. Ты главный и ты сам решаешь какие профили качества тебе сформулировать. Разделять комплекты правил, менять приоритет и т.д.


#16

То есть это зона ответственности Руководителя всей разработки по конкретному языку. То есть руководителя центра компетенции по 1С.

Здесь полностью согласен, более того, права на пометку “неактуально” или “ложное срабатывание” тоже не стоит предоставлять никому, за исключением архитектора / рука, в противном случае появляется соблазн “замести под ковер”.


#17

В ответ могу попросить перестать переходить на личности и быть адекватнее, что в публичном пространстве, что в “приватных” разговорах. Моё изначальное предложение было вполне “по теме”, а твоё реагирование конкретно на эту проверку я неоднократно наблюдал лично.


#18

Своим постом я обратил внимание что ситуация чуть шире, чем предлагалось тобой. Больше ничего.

Кто первый начал добавлять личного в формулировки - предлагаю не обсуждать и оставить каждому при себе.

Есть мысли добавить на форум стороннего модератора. Надо подумать на досуге кому бы можно предложить эту роль, почетную.


#19

Предложение распилить правило (если вдруг еще не сделано).

  1. Разыменование в полях, с низким (кодсмелл)
  2. Разыменование в секции ГДЕ или в условии соединения, с высоким(перфоманс).