Обсудить: Правило "Неоднократное выполнение одного и того же выражения в рамках одного метода"

sonar-bsl-plugin

#1

Товарищи, хотел бы обсудить полезность и нужность возможного правила “Неоднократное выполнение одного и того же выражения в рамках одного метода”

Причины:

  • Исключение копипаста
  • упрощение структуры кода
  • возможное ускорение выполнения за счет отключения повторного вычисления
  • что еще?
  • [ ] Выражение
  • [ ] в т.ч. и вызов метода

Например, ТипЗнч(ВладелецСвойств) в след.блоке лучше заменить на переменную

Функция ПолучитьНаборыСвойствОбъекта(Знач ВладелецСвойств, КлючНазначения = Неопределено) Экспорт
	
	Если ТипЗнч(ВладелецСвойств) = Тип("ДанныеФормыСтруктура") Тогда
		ТипСсылки = ТипЗнч(ВладелецСвойств.Ссылка)
	ИначеЕсли ОбщегоНазначения.ЭтоСсылка(ТипЗнч(ВладелецСвойств)) Тогда
		ТипСсылки = ТипЗнч(ВладелецСвойств);
	Иначе
		ТипСсылки = ТипЗнч(ВладелецСвойств.Ссылка)
	КонецЕсли;

@all Что скажете?


#2

Очевидно, в условиях Ссылка = ...

а за условиями ТипСсылки = ТипЗнч(Ссылка);


#3

Пример не самый сложный, человек явно отрефакторит лучше, чем машина.

Но подсказку дать очень полезно.


#4

Похоже на преждевременную оптимизацию (которая есть корень всякого зла). Часто локальные временные переменные затрудняют понимание и рефакторинг, поэтому нужно всегда смотреть на реальный выигрыш в производительности, и насколько при этом оправдана цена уменьшения понятности когда.


#5

Не соглашусь.
В рамках кода 1С очень часто злоупотребляют одни и теми же вызовами в соседних строчках.
А так как у нас интерпретатор и кеша при исполнении фактически нет, он юзается только для данных из БД, очень часто и выполнение тупит и читать сложно :frowning:


#6

Как по мне, так я тоже считаю, что правило неоднозначное. Я бы не спешил с его введением.


#7

А в Сонаре есть градации для срабатываний, типа Error/Warning? Можно было бы квалифицировать такое не как ошибку, а как предупреждение, например.


#8

Есть критичность - Мажор, минос и т.д. И есть Ошибка, Уязвимость и “Пахнущий код”