Требование Обоснование при подавлении ошибки

Я использую TFS, чтобы потребовать от разработчиков использования анализа кода с помощью политики регистрации. Если возникают какие-либо ошибки, они не могут проверить свой код.Требование Обоснование при подавлении ошибки

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

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

источник

2014-02-14 Matthijs

«Они» всегда делают плохое дело. Или становитесь частью их и переходите на «мы никогда не проверяем плохой код» или избиваем «их» палкой, пока «они» не будут счастливы ... Не совсем ясно, какая часть вашего сообщения связана с кодом - изменения всегда в контроль источника, поэтому ясно, когда кто-то обманул. Так почему бы не предположить, что разработчики не обманывают и не делают с ним? –

Я никогда не говорил «они», мы делаем плохие вещи. Я просто подразумеваю, что программисты могут лениться и, требуя, чтобы они заполнили простой комментарий, объясняющий причину suppresion, я могу позже проверить, почему они подавили эти ошибки. Если я разрешу им подавить ошибку, в чем смысл даже показывать эти ошибки? Я хочу скопировать какой-то «правильный» код, который можно автоматически выполнить с помощью этого анализа кода. Но опять же, если они подавляют показанную ошибку, я хочу знать, почему. Так что, пожалуйста, знаете ли вы, как это настроить? – Matthijs

Я не думаю, что есть ... Вы могли бы написать свое собственное, хотя. Если вы посмотрите на Power Tools TFS, они добавили несколько дополнительных политик регистрации.

http://msdn.microsoft.com/en-us/library/ms181281(v=vs.90).aspx

источник

2014-02-14 13:47:39

Вы можете добавить пользовательский анализ кода правило для проверки отсутствия или пустых оправданий. Пример: http://www.binarycoder.net/fxcop/html/ex_specifysuppressmessagejustification.html.

источник

2014-02-14 14:10:18

Что можно затем подавить, чтобы он не искал других оправданий? – Matthijs

Да, но только с обоснованием. ;) На несколько более серьезной ноте, если вы заботитесь об обоснованиях, они должны быть включены в обзоры ручного кода, поэтому такое правило действительно является фильтром для очень очевидных проблем. –

Нет, не с Обоснованием, потому что вы можете подавить недавно реализованный Justificationrule, позволяя SuppressMessages быть без Обоснования снова и снова. Правило, подобное этому, является отчасти устаревшим, поскольку это приводит к той же проблеме, что и все другие ошибки анализа кода; они могут быть подавлены, что приводит к их пропуску. – Matthijs

Почему бы не настроить сервер сборки и не использовать закрытые чек-листы. Затем установите определение сборки, чтобы всегда выполнять анализ кода. Если анализ кода завершится неудачно, сборка завершится неудачно (если это будет настроено в наших проектах), и регистрация не произойдет, пока они не исправит анализ кода, из-за чего сборка завершится с ошибкой.

источник

2014-02-14 22:56:55 mikanyg

Как уже говорилось ранее, вы можете устранить эти ошибки, позволяя программе создавать и пропускать ошибки, которые вы подавили. Так что это действительно не вариант, потому что я уже применяю анализ кода через TFS. – Matthijs

Требование Обоснование при подавлении ошибки

ответ

Смежные вопросы