Лучшие комментарии
(3) ну, например, чтобы:
- не настраивать ответственных по объектам метаданных в АПК: SonarQube сам определит ответственного за косячный код по git blame;
- разделить ошибки на legacy и привнесённые в новом коде, старый код не трогать, а сосредоточиться на исправлении новых косяков;
- видеть ошибки АПК в контексте окружающего кода, а не только модуль и номер строки;
- ускорить отображение отчётов;
- получать постоянные ссылки на ошибки, чтобы взять их на контроль и добиться исправления.
- не настраивать ответственных по объектам метаданных в АПК: SonarQube сам определит ответственного за косячный код по git blame;
- разделить ошибки на legacy и привнесённые в новом коде, старый код не трогать, а сосредоточиться на исправлении новых косяков;
- видеть ошибки АПК в контексте окружающего кода, а не только модуль и номер строки;
- ускорить отображение отчётов;
- получать постоянные ссылки на ошибки, чтобы взять их на контроль и добиться исправления.
(4) Вы можете делать коммиты, связанные с обновлением типовых конфигураций (обновлением БСП или переходом на новую версию типовой конфигурации) от имени специально выделенного пользователя. Для этого достаточно перед коммитом указать в качестве e-mail автора служебный или свой второй e-mail. Тогда изменения типовой конфигурации привяжутся не к тем пользователям, под которым ведется регулярная разработка.
В этом случае разработчики получат возможность видеть и исправлять только свои ошибки. В общем случае вы будете видеть и ошибки типовой, но в этом нет ничего плохого. Их всегда можно будет отбросить на основании авторства изменений.
Если вы пользуетесь АПК, то ситуация будет аналогична: если Вы дорабатываете типовой модуль и хотите его проверить после доработки, то в результаты его проверки попадет и типовой код и Ваш. АПК позволяет фильтровать объекты конфигурации, подлежащие проверке, а не части модулей. При использовании возможностей git как раз появляется возможность проверять только внесенные в модуль изменения в привязке к авторам.
В этом случае разработчики получат возможность видеть и исправлять только свои ошибки. В общем случае вы будете видеть и ошибки типовой, но в этом нет ничего плохого. Их всегда можно будет отбросить на основании авторства изменений.
Если вы пользуетесь АПК, то ситуация будет аналогична: если Вы дорабатываете типовой модуль и хотите его проверить после доработки, то в результаты его проверки попадет и типовой код и Ваш. АПК позволяет фильтровать объекты конфигурации, подлежащие проверке, а не части модулей. При использовании возможностей git как раз появляется возможность проверять только внесенные в модуль изменения в привязке к авторам.
(12) На скриншоте тестовый проект, где ~800 ошибок, был проверен только в рамках статьи.
Во вложении метрики самописного проекта не на БСП, над который сейчас ведутся работы по улучшению качества кода (этот же скриншот есть в статье).
Если смотреть тренд количества ошибок, дублирования кода - то их количество со временем уменьшается.
Во вложении метрики самописного проекта не на БСП, над который сейчас ведутся работы по улучшению качества кода (этот же скриншот есть в статье).
Если смотреть тренд количества ошибок, дублирования кода - то их количество со временем уменьшается.
Прикрепленные файлы:
Остальные комментарии
Избранное
Подписка
Сортировка:
Древо
(41) Так оно наверняка у вас не работает, и вы уже тратите ресурсы на поиск этой ошибки. Если это в "не используемом" функционале, то конечно фиг бы с ней. Это если про вендорный код. А в своем в принципе сразу видите "ой тут наверное что то не так" и исправляете.
(37) В 1С в некоторых отделах, на некоторых продуктах работают весьма отзывчивые люди. Присланный им на партнерке или в саппорт репорт внезапно не отфутболивается, баг или недоработка берется в работу и исправляется, а сами сотрудники тебе благодарны за помощь.
Такое случается не везде, но если случается, то вселяет веру в людей и надежду что наше дело - "правое".
Такое случается не везде, но если случается, то вселяет веру в людей и надежду что наше дело - "правое".
(3)автоматизированно в контуре ci проводить анализ состояния системы и с помощью sonarqube видеть общий тренд изменения качества решений. Так же, на мой взгляд, одна из самых главных "плюшек" сонара - привязка результатов диагностик к пользователям через git blame. Для меня ещё полезным показалось дублирование кода - этого соответственно нет в АПК.
(3) ну, например, чтобы:
- не настраивать ответственных по объектам метаданных в АПК: SonarQube сам определит ответственного за косячный код по git blame;
- разделить ошибки на legacy и привнесённые в новом коде, старый код не трогать, а сосредоточиться на исправлении новых косяков;
- видеть ошибки АПК в контексте окружающего кода, а не только модуль и номер строки;
- ускорить отображение отчётов;
- получать постоянные ссылки на ошибки, чтобы взять их на контроль и добиться исправления.
- не настраивать ответственных по объектам метаданных в АПК: SonarQube сам определит ответственного за косячный код по git blame;
- разделить ошибки на legacy и привнесённые в новом коде, старый код не трогать, а сосредоточиться на исправлении новых косяков;
- видеть ошибки АПК в контексте окружающего кода, а не только модуль и номер строки;
- ускорить отображение отчётов;
- получать постоянные ссылки на ошибки, чтобы взять их на контроль и добиться исправления.
(14)
В последних версиях АПК появился режим "поместить все ошибки в исключения" как раз для первоначального занесения всех ошибок в исключения в старом коде.
- разделить ошибки на legacy и привнесённые в новом коде, старый код не трогать, а сосредоточиться на исправлении новых косяков;
В последних версиях АПК появился режим "поместить все ошибки в исключения" как раз для первоначального занесения всех ошибок в исключения в старом коде.
(85)
Этот сценарий я рассматриваю как потенциально опасный, т.к. маскирует потенциальные ошибки.
Пример:у меня эпизодически проявляется ошибка "Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)!"
Я открываю SonarQube, ставлю фильтр на каталог по имени модуля и вижу там ошибку "Отсутствует исключительная управляемая блокировка на записываемые (удаляемые) данные." - эта ошибка унаследованная, привнесена была год назад, но благодаря связке АПК+SonarQube я могу определить причину и исправить ошибку.
Так что, если поместить все старые ошибки в исключения, возможности оперативно диагностировать источник ошибки у меня не будет.
В последних версиях АПК появился режим "поместить все ошибки в исключения" как раз для первоначального занесения всех ошибок в исключения в старом коде.
Этот сценарий я рассматриваю как потенциально опасный, т.к. маскирует потенциальные ошибки.
Пример:у меня эпизодически проявляется ошибка "Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)!"
Я открываю SonarQube, ставлю фильтр на каталог по имени модуля и вижу там ошибку "Отсутствует исключительная управляемая блокировка на записываемые (удаляемые) данные." - эта ошибка унаследованная, привнесена была год назад, но благодаря связке АПК+SonarQube я могу определить причину и исправить ошибку.
Так что, если поместить все старые ошибки в исключения, возможности оперативно диагностировать источник ошибки у меня не будет.
На практике или дописываю типовую конфу, или делаю свою на базе БСП. В обоих случаях собственного кода в общем объеме не так и много. Можно ли анализировать только отличия от типовой? Зачем мне знать качество кода других программистов, раз на них никак не влияю...
(4) Вы можете делать коммиты, связанные с обновлением типовых конфигураций (обновлением БСП или переходом на новую версию типовой конфигурации) от имени специально выделенного пользователя. Для этого достаточно перед коммитом указать в качестве e-mail автора служебный или свой второй e-mail. Тогда изменения типовой конфигурации привяжутся не к тем пользователям, под которым ведется регулярная разработка.
В этом случае разработчики получат возможность видеть и исправлять только свои ошибки. В общем случае вы будете видеть и ошибки типовой, но в этом нет ничего плохого. Их всегда можно будет отбросить на основании авторства изменений.
Если вы пользуетесь АПК, то ситуация будет аналогична: если Вы дорабатываете типовой модуль и хотите его проверить после доработки, то в результаты его проверки попадет и типовой код и Ваш. АПК позволяет фильтровать объекты конфигурации, подлежащие проверке, а не части модулей. При использовании возможностей git как раз появляется возможность проверять только внесенные в модуль изменения в привязке к авторам.
В этом случае разработчики получат возможность видеть и исправлять только свои ошибки. В общем случае вы будете видеть и ошибки типовой, но в этом нет ничего плохого. Их всегда можно будет отбросить на основании авторства изменений.
Если вы пользуетесь АПК, то ситуация будет аналогична: если Вы дорабатываете типовой модуль и хотите его проверить после доработки, то в результаты его проверки попадет и типовой код и Ваш. АПК позволяет фильтровать объекты конфигурации, подлежащие проверке, а не части модулей. При использовании возможностей git как раз появляется возможность проверять только внесенные в модуль изменения в привязке к авторам.
(9) Итак, получилось развернуть, но обо всем по порядку:
До этого разворачивал SonarQube 7.7 на стандартном порте 9000 - особо не успел разобраться, но он работал.
Затем, после вашей статьи, решил обновиться до 7.9. И весь вчерашний день решал головоломку, почему он то запускается, то падает.
Оказалось дело в jdk 11, странно что он без нее работал (но как-то криво)
Так что про jdk не забываем :)
Из статьи не понятен был момент - нужно ли создавать проект с ключем в SonarQube или он автоматом сам создастся?
Я создал проект, и в файле настроек указал параметры проекта.
И я в итоге сделал вот так
.../sonar-scanner.bat -D"project.settings=../sonar-project.properties"
а дальше в sonar-project.properties указал путь к проекту:
***
sonar.projectBaseDir=С:/myrepos/myprjkt
***
Кстати не забываем что слэш должен быть в файлике настроек именно "/" - а то пару раз косякнул с этим
И мое микро замечание - в секции примера слэш хорошо бы тоже одного направления сделать
"Без токена:
../sonar-scanner-cli-4.0.0.1744-windows\sonar-scanner-4.0.0.1744-windows/bin/sonar-scanner.bat
С токеном:
../sonar-scanner-cli-4.0.0.1744-windows\sonar-scanner-4.0.0.1744-windows/bin/sonar-scanner.bat -D"sonar.login=1952877e4d61d69c766eb8d9ca1d39ac48a4254f"
"
До этого разворачивал SonarQube 7.7 на стандартном порте 9000 - особо не успел разобраться, но он работал.
Затем, после вашей статьи, решил обновиться до 7.9. И весь вчерашний день решал головоломку, почему он то запускается, то падает.
Оказалось дело в jdk 11, странно что он без нее работал (но как-то криво)
Так что про jdk не забываем :)
Из статьи не понятен был момент - нужно ли создавать проект с ключем в SonarQube или он автоматом сам создастся?
Я создал проект, и в файле настроек указал параметры проекта.
И я в итоге сделал вот так
.../sonar-scanner.bat -D"project.settings=../sonar-project.properties"
а дальше в sonar-project.properties указал путь к проекту:
***
sonar.projectBaseDir=С:/myrepos/myprjkt
***
Кстати не забываем что слэш должен быть в файлике настроек именно "/" - а то пару раз косякнул с этим
И мое микро замечание - в секции примера слэш хорошо бы тоже одного направления сделать
"Без токена:
../sonar-scanner-cli-4.0.0.1744-windows\sonar-scanner-4.0.0.1744-windows/bin/sonar-scanner.bat
С токеном:
../sonar-scanner-cli-4.0.0.1744-windows\sonar-scanner-4.0.0.1744-windows/bin/sonar-scanner.bat -D"sonar.login=1952877e4d61d69c766eb8d9ca1d39ac48a4254f"
"
(93)
Протестировал на маленькой базе - все нормально отработало.
Запустил аналогично на большой базе - 4 часа скрипт работал, и самое что странное ругнулся в самом конце
ERROR Caused by: GC overhead limit exceded
что еще странно что процент выполнения проверки файлов тормозиться по экспоненте. И последние 10 файлов проверялись 1 час.
Попробовал дописать исключение в файл настроек конкретного проекта -
sonar.exclusions= .... (кстати было бы круто если бы статье был пример шаблонных исключений)
Но ничего не поменялось.
Пишут в интернетах про SONAR_SCANER_OPTS - но я не пойму, это переменная среды? Если нет, то где ее надо указать? Где можно посмотреть сколько памяти используется фактически?
Мне не критично если анализ будет хоть целый день идти, его каждый день запускать смысла нет.
Протестировал на маленькой базе - все нормально отработало.
Запустил аналогично на большой базе - 4 часа скрипт работал, и самое что странное ругнулся в самом конце
ERROR Caused by: GC overhead limit exceded
что еще странно что процент выполнения проверки файлов тормозиться по экспоненте. И последние 10 файлов проверялись 1 час.
Попробовал дописать исключение в файл настроек конкретного проекта -
sonar.exclusions= .... (кстати было бы круто если бы статье был пример шаблонных исключений)
Но ничего не поменялось.
Пишут в интернетах про SONAR_SCANER_OPTS - но я не пойму, это переменная среды? Если нет, то где ее надо указать? Где можно посмотреть сколько памяти используется фактически?
Мне не критично если анализ будет хоть целый день идти, его каждый день запускать смысла нет.
(103) спасибо! Проверю:)
Да в статье описано, но у меня "Parsing files" не застряло где-то, а прошло все 100% и дальше стопорнулось.
SONAR_SCANNER_OPTS - по идее я эту настройку ранее уже выставил, просто связи с реальностью пока не увидел, возможно где-то очепятался, буду тестировать :)
Да в статье описано, но у меня "Parsing files" не застряло где-то, а прошло все 100% и дальше стопорнулось.
SONAR_SCANNER_OPTS - по идее я эту настройку ранее уже выставил, просто связи с реальностью пока не увидел, возможно где-то очепятался, буду тестировать :)
(103)
Проверил. Если ставлю 14Гб, то parsing files стопорится на 82%
При этом память используется на 98%
Если ставлю 8Гб, то Parsing files доходит почти до конца, но на 10-20 последних файлах все валится.
Какие решения вижу я - попробовать исключить ряд 1С-
модулей оригинальной конфы. Но решение так себе.
Конечно, увеличив мощность сервака, наверное все сработает, но может есть другой вариант?
Второй вариант - разбить на два проекта, по принципу - в первом проекте только справочники, во второй только документы.
Есть еще идеи? Может еще что то можно подкрутить?
Проверил. Если ставлю 14Гб, то parsing files стопорится на 82%
При этом память используется на 98%
Если ставлю 8Гб, то Parsing files доходит почти до конца, но на 10-20 последних файлах все валится.
Какие решения вижу я - попробовать исключить ряд 1С-
модулей оригинальной конфы. Но решение так себе.
Конечно, увеличив мощность сервака, наверное все сработает, но может есть другой вариант?
Второй вариант - разбить на два проекта, по принципу - в первом проекте только справочники, во второй только документы.
Есть еще идеи? Может еще что то можно подкрутить?
(10)
"Предупреждён — значит вооружён". Теперь мы понимаем что у нас есть 2 тыс. критических проблем и 44 уязвимости. Их нужно устранять, чтобы сделать решение более стабильным. Так же нужно учитывать, что большая часть кода - это код на поддержке. Его нужно исключить. Для этого можно использовать проект . Далее используя анализ на продолжительном периоде, можно отслеживать новые ошибки / дефекты с помощью отбора по дате создания замечания. (см. приложенный файл)
Еще вопрос: т.к. используются обычные формы, перед анализом, были ли они извлечены? Например через gitsync. Я для этого использую скрипт .
И что дальше? Как качеством управлять то?
"Предупреждён — значит вооружён". Теперь мы понимаем что у нас есть 2 тыс. критических проблем и 44 уязвимости. Их нужно устранять, чтобы сделать решение более стабильным. Так же нужно учитывать, что большая часть кода - это код на поддержке. Его нужно исключить. Для этого можно использовать проект . Далее используя анализ на продолжительном периоде, можно отслеживать новые ошибки / дефекты с помощью отбора по дате создания замечания. (см. приложенный файл)
Еще вопрос: т.к. используются обычные формы, перед анализом, были ли они извлечены? Например через gitsync. Я для этого использую скрипт .
Прикрепленные файлы:
(12) На скриншоте тестовый проект, где ~800 ошибок, был проверен только в рамках статьи.
Во вложении метрики самописного проекта не на БСП, над который сейчас ведутся работы по улучшению качества кода (этот же скриншот есть в статье).
Если смотреть тренд количества ошибок, дублирования кода - то их количество со временем уменьшается.
Во вложении метрики самописного проекта не на БСП, над который сейчас ведутся работы по улучшению качества кода (этот же скриншот есть в статье).
Если смотреть тренд количества ошибок, дублирования кода - то их количество со временем уменьшается.
Прикрепленные файлы:
(11)
Скажите пожалуйста, получается то есть, если проект на обычных формах - каждый раз, перед выгрузкой файлов конфигурации в project/src (ну или перед выгрузкой этих же файлов git) - их нужно разобрать? И код из ссылки это все корректно делает?
За статью - спасибо, очень большая и ценная работа проделана
Скажите пожалуйста, получается то есть, если проект на обычных формах - каждый раз, перед выгрузкой файлов конфигурации в project/src (ну или перед выгрузкой этих же файлов git) - их нужно разобрать? И код из ссылки это все корректно делает?
За статью - спасибо, очень большая и ценная работа проделана
Коллеги, знаю, что бесплатный сонар позволяет анализировать одну ветку. В примере из статьи - это master. По содержимое ветки master - это то, что находится в боевой системе. Получается, что контроль качества выполняется после публикации изменений? Или я что-то неправильно понял? Пробуем использовать инструменты контроля качества. И пока не получается запустить инструмент так, чтобы он проверял изменения каждого разработчика перед публикацией.
(26) если работаете в EDT, то можно доустановить плагин от Александра Капралова, который будет показывать диагностики из BSL LS прямо в EDT.
А так да, выше дали ссылку на комьюнити бранч-плагин, лично проверял его работу на 4 серверах от 7.4 до 7.8.
Недавно вышел релиз плагина под свежий LST релиз SonarQube, конкретно его я еще не проверял, но в комментариях пишут, что работает.
А так да, выше дали ссылку на комьюнити бранч-плагин, лично проверял его работу на 4 серверах от 7.4 до 7.8.
Недавно вышел релиз плагина под свежий LST релиз SonarQube, конкретно его я еще не проверял, но в комментариях пишут, что работает.
Спасибо за статью!
Читая комментарии под статьями такого рода, иной раз, поражаюсь токсичности комьюнити.
Читая комментарии под статьями такого рода, иной раз, поражаюсь токсичности комьюнити.
(34) радует, что не все комьюнити с менталитетом кодера "сказали-делаю, а вот это все остальное - для меня сложно" чем прогрессивнее будет комьюнити, тем лучше со временем станут условия для 1с разработчиков не как добывателей денег, а как специалистов.
Статья отличная, спасибо!
Вопрос не в тему, но по скриншоту из темы - почему "Если ИначеЕсли" должна обязательно содержать Иначе?
Зачем сюда Иначе пихать, если Иначе ничего не нужно?
Вопрос не в тему, но по скриншоту из темы - почему "Если ИначеЕсли" должна обязательно содержать Иначе?
КолвоОчков = 10;
Если Ничья Тогда
КолвоОчков = КолвоОчков + 1;
ИначеЕсли Победа Тогда
КолвоОчков = КолвоОчков + 3;
КонецЕсли;
ЗаписатьВТурнирнуюТаблицу(КолвоОчков); ПоказатьЗачем сюда Иначе пихать, если Иначе ничего не нужно?
(47) это проверка из разряда "защитного программирования". Нужно на 100% быть уверенным, что это не "иначе" продолбали, а просто предварительную инициализацию сделали. Плюс не во всех ветках бывает такой простой инкремент, где-то могут вызываться функции с побочным эффектом.
Уверены, что в данном случае все в порядке? ставьте на конкретное срабатывание статус won't fix.
Уверены, что всегда все ок или вас эта проверка раздражает - выключайте проверку в настройках "Quality Profile" или в конфигурационном файле BSL Language Server (в зависимости от режима запуска)
Уверены, что в данном случае все в порядке? ставьте на конкретное срабатывание статус won't fix.
Уверены, что всегда все ок или вас эта проверка раздражает - выключайте проверку в настройках "Quality Profile" или в конфигурационном файле BSL Language Server (в зависимости от режима запуска)
(47)Формально у вас еще и копипаста в подсчете очков.
КолвоОчков = 10;
Если Ничья Тогда
Инкремент = 1;
ИначеЕсли Победа Тогда
Инкремент = 3
ИначеЕсли ФикирБылПьян Тогда
Инкремент = 10;
Иначе
Инкремент = 0;
КонецЕсли;
КолвоОчков = КолвоОчков + Инкремент;
ЗаписатьВТурнирнуюТаблицу(КолвоОчков);
Показать
(50)
Копипаста - звучит как что-то плохое) Я бы в данном контексте его не использовал. Потому что у меня нет Иначе, а без него мне не нужен Инкремент, он в конце ошибку даст. Потому что формально в вашем примере добавлено одно ненужное действие, которое может выполняться, например, в цикле, например, миллион раз - и вот уже у нас миллион ненужных действий. Если же Инкремент вынести за Если, то тогда у нас миллион ненужных присваиваний переменных.
Копипаста - звучит как что-то плохое) Я бы в данном контексте его не использовал. Потому что у меня нет Иначе, а без него мне не нужен Инкремент, он в конце ошибку даст. Потому что формально в вашем примере добавлено одно ненужное действие, которое может выполняться, например, в цикле, например, миллион раз - и вот уже у нас миллион ненужных действий. Если же Инкремент вынести за Если, то тогда у нас миллион ненужных присваиваний переменных.
(47) Холиварная тема. У меня в коде больше таких условий:
КолвоОчков = 10;
Если Ничья Тогда
КолвоОчков = КолвоОчков + 1;
ИначеЕсли Победа Тогда
КолвоОчков = КолвоОчков + 3;
Иначе
ВызватьИсключение("Никогда такого не было и вот опять");
КонецЕсли;
ЗаписатьВТурнирнуюТаблицу(КолвоОчков);
Показать
(60)
Тут я могу только начать реальный холивар, заявив, что это не функция кода - объяснять бизнес-логику, что для этого должно быть ТЗ, документация и комментарии:
Причём, не отменяя нужность документации, думаю, важнее всего как раз такое писать в комментарии, потому что он ближе всего к программисту.
Тут я могу только начать реальный холивар, заявив, что это не функция кода - объяснять бизнес-логику, что для этого должно быть ТЗ, документация и комментарии:
КолвоОчков = 10;
Если Ничья Тогда
КолвоОчков = КолвоОчков + 1;
ИначеЕсли Победа Тогда
КолвоОчков = КолвоОчков + 3;
// проигрыш - кол-во не меняется,
// никаких других ситуаций не бывает
КонецЕсли;
ЗаписатьВТурнирнуюТаблицу(КолвоОчков); ПоказатьПричём, не отменяя нужность документации, думаю, важнее всего как раз такое писать в комментарии, потому что он ближе всего к программисту.
(64) Вот именно в Иначе и нужно вставить этот комментарий, чтоб всем остальным было очевидно, что здесь не продолбали вариант с проигрышем. А еще лучше, чтоб волшебные цифры 0, 1 и 3 были инкапсулированы
Если Ничья Тогда
выигрыш = КоличествоОчковПриНичьей();
ИначеЕсли Победа Тогда
выигрыш = КоличествоОчковПриПобеде();
Иначе
выигрыш = КоличествоОчковПриПоражении();
КонецЕсли;
КолвоОчков = КолвоОчков + выигрыш;
ЗаписатьВТурнирнуюТаблицу(КолвоОчков); Показать
(71) Этот пример в итоге показал, что затраты на Иначе окупились бы. Эта проверка на тех. долг. А тех. долг влияет на сопровождаемость - то есть насколько легко этот код смогут доработать другие программисты. Пример Олега показал, что именно в этом месте этот тех.долг выстрелил в ногу, а значит сонар очень даже правильно диагностировал проблему.
На моем реальном боевом проекте я тож сперва был скептически настроен к этой проверке. Психанул и везде, где в Иначе не должны заходить никогда расставил вызов исключений. И я очень удивился, когда у меня тесты отвалились.
На моем реальном боевом проекте я тож сперва был скептически настроен к этой проверке. Психанул и везде, где в Иначе не должны заходить никогда расставил вызов исключений. И я очень удивился, когда у меня тесты отвалились.
(73)
Каким образом? Вы показали будущему программисту логику через Иначе (т.е. ещё одну команду и даже вызов функции), я - комментарием. Информация та же, вызовов меньше.
(73)
Возможно, нужно внимательнее подходить к разработке. Если вы говорите, что в Иначе не должно заходить никогда, а у вас исключения полезли, то тем, что вы сделаете пустое Иначе, вы проблему не решите.
Этот пример в итоге показал, что затраты на Иначе окупились бы.
Каким образом? Вы показали будущему программисту логику через Иначе (т.е. ещё одну команду и даже вызов функции), я - комментарием. Информация та же, вызовов меньше.
(73)
И я очень удивился, когда у меня тесты отвалились.
Возможно, нужно внимательнее подходить к разработке. Если вы говорите, что в Иначе не должно заходить никогда, а у вас исключения полезли, то тем, что вы сделаете пустое Иначе, вы проблему не решите.
(74)
> Вы показали будущему программисту логику через Иначе
И комментарий и логика используют ветку Иначе и поэтому стало понятнее и сложнее совершить ошибку. Можно обойтись и комментарием. Главный посыл в том, что ветка Иначе тут нужна.
> Возможно, нужно внимательнее подходить к разработке.
Да-да, нужно. Нужно писать без ошибок. У меня не получается. Поэтому я использую всякие вспомогательные костыли, типа статистического анализа кода, код-ревью, тесты и прочую ненужную вещь, чтобы снизить количество ошибок. Исключение в блоке иначе, в который никогда не должны бы заходить работает значительно лучше, чем отсутствие такого блока в принципе, потому что мы посчитали, что сюда не должны бы зайти.
> Вы показали будущему программисту логику через Иначе
И комментарий и логика используют ветку Иначе и поэтому стало понятнее и сложнее совершить ошибку. Можно обойтись и комментарием. Главный посыл в том, что ветка Иначе тут нужна.
> Возможно, нужно внимательнее подходить к разработке.
Да-да, нужно. Нужно писать без ошибок. У меня не получается. Поэтому я использую всякие вспомогательные костыли, типа статистического анализа кода, код-ревью, тесты и прочую ненужную вещь, чтобы снизить количество ошибок. Исключение в блоке иначе, в который никогда не должны бы заходить работает значительно лучше, чем отсутствие такого блока в принципе, потому что мы посчитали, что сюда не должны бы зайти.
(75)
Одно дело - посчитали, другое дело - уверены. В указанном мною высосанном из пальца примере, никаких других вариантов быть не может, соответственно, Иначе просто можно выкинуть. Выкидывать Иначе там, где я не знаю, зайдут туда или нет - я не предлагал)
И повторюсь - исключениями вы неправильную логику не почините. Исключения в Иначе могут быть полезны на этапе разработки, чтобы было понятно, что за данные идут и что делать. После понимания, исправления и т.п. эти Исключения, которые остались невызванными, нужно удалить, туда же можно удалить и Иначе, которые останутся пустыми.
Правила нужны для того, чтобы облегчать жизнь. Если правилам следуют просто формально, то это, видимо, неправильные или неправильно понятые правила. За добрый десяток постов мне так и не показали, где в моём абстрактном примере мне понадобится Иначе. А пихать его просто потому, что где-то кто-то сказал, что Иначе должно быть - не знаю почему, но не хочется)
потому что мы посчитали, что сюда не должны бы зайти
Одно дело - посчитали, другое дело - уверены. В указанном мною высосанном из пальца примере, никаких других вариантов быть не может, соответственно, Иначе просто можно выкинуть. Выкидывать Иначе там, где я не знаю, зайдут туда или нет - я не предлагал)
И повторюсь - исключениями вы неправильную логику не почините. Исключения в Иначе могут быть полезны на этапе разработки, чтобы было понятно, что за данные идут и что делать. После понимания, исправления и т.п. эти Исключения, которые остались невызванными, нужно удалить, туда же можно удалить и Иначе, которые останутся пустыми.
Правила нужны для того, чтобы облегчать жизнь. Если правилам следуют просто формально, то это, видимо, неправильные или неправильно понятые правила. За добрый десяток постов мне так и не показали, где в моём абстрактном примере мне понадобится Иначе. А пихать его просто потому, что где-то кто-то сказал, что Иначе должно быть - не знаю почему, но не хочется)
(89) Не всем повезло с умением писать сразу код без ошибок, который в последствии не требует сопровождения и доработок.
Исключения удалять как раз нельзя. Они нужны не для того, чтобы падало при разработке, а для того, чтобы падало, когда кто-нить другой в каком-нить другом месте сделал некорректную доработку.
Чем проще система, чем меньше программистов участвует в разработке и чем меньше ущерб от ошибок в ней - тем меньше можно заморачиватся с внутренним качеством.
Исключения удалять как раз нельзя. Они нужны не для того, чтобы падало при разработке, а для того, чтобы падало, когда кто-нить другой в каком-нить другом месте сделал некорректную доработку.
Чем проще система, чем меньше программистов участвует в разработке и чем меньше ущерб от ошибок в ней - тем меньше можно заморачиватся с внутренним качеством.
(65) хм... разве это защитное программирование?
вот мой вариант:
ведь может что то сломаться - и партия будет незавершенная...
вот мой вариант:
РезультатПартии = 0;
Если СтатусПартии = Статусы().Ничья Тогда
РезультатПартии = 1;
ИначеЕсли СтатусПартии = Статусы().Победа Тогда
РезультатПартии = 3;
ИначеЕсли СтатусПартии = Статусы().Поражение Тогда
РезультатПартии = 0;
Иначе
//ВызватьИсключение("Некорректный статус партии: " + СтатусПартии);
// или не вызывать....
СтатусПартии = Статусы().Дисквалификация;
КолвоОчков = 0;
КонецЕсли;
КолвоОчков = КолвоОчков + РезультатПартии;
ЗаписатьВТурнирнуюТаблицу(КолвоОчков); Показатьведь может что то сломаться - и партия будет незавершенная...
(64)Нас же предупреждали, что это диагностика холиварная. На примерах разобрали, что придумана не из воздуха. В планах есть добавить настройку, что бы она срабатывала только на СелектКейсах.
Использовать ее на своих проектах или нет, решаете вы сами.
P.S. У некоторых диагностик есть параметры. Например, можно увеличить ограничение на длину строки (Стандарт глосит: 120. Имхо: 140).
Использовать ее на своих проектах или нет, решаете вы сами.
P.S. У некоторых диагностик есть параметры. Например, можно увеличить ограничение на длину строки (Стандарт глосит: 120. Имхо: 140).
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|