Использование Resharper - это действительно «личное решение»?

Question

Мой руководитель группы рекомендует всем разработчикам использовать ReSharper, но он не "применяет" эту рекомендацию. В результате, всякий раз, когда я открываю какой-то код, он сразу же выскакивает, использует ли разработчик, который его написал, ReSharper или нет. Контрольными знаками являются ненужное вложение, использование избыточных объявлений типов и общих параметров, опечатки в именах символов (потому что было бы слишком трудно их исправить) и т. Д.

Похоже, что неустановленное предположение состоит в том, что пользователь ReSharper - это «личное решение», которое ни на кого не влияет. Но так ли это на самом деле? Какой уровень «принуждения» в этом вопросе идеален?

Answer 1

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

Answer 2

<Opinion>

Я думаю, что использование таких инструментов, как ReSharper, должно определяться так же, как реализуются соглашения о стилях. Все это делают. Или никто этого не делает.

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

</Opinion>

Answer 3

Вы должны написать код, который соответствует стандартам кодирования, согласованным вашей командой (что-то вроде , этого достаточно ). Ваш выбор плагинов VS, привязок клавиатуры, цветов и размеров шрифта должен оставаться вашим собственным.

Я бы не стал слишком беспокоиться о таких мелочах, как "избыточные объявления типов". Более важно привлечь людей на борт с принципами SOLID.

Answer 4

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

Сказав, что кажется, что "проблема", с которой вы столкнулись, связана с качеством кода и не связана с R #. Ошибки, которые вы описываете, могут быть созданы с или без R #, и их можно избежать, выполнив обзоры кода или парное программирование.

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

Answer 5

После использования R # более 2 лет, я сочувствую вам. Я нахожу свой код значительно чище, лаконичнее и читабельнее. И мои стандарты как для моего собственного кода, так и для кода, который я должен проверять / поддерживать у других, сделали качественный скачок вверх. Однако основополагающее правило политики (на самом деле человеческая природа) заключается в том, что большинство людей сопротивляются переменам ... и навязывание их им никогда не снижает этого сопротивления, поэтому убеждение всегда лучше ...

Answer 6

Для меня использование инструмента рефакторинга кода - легкая задача. Подумайте об этом - вы не пишете код для себя, вы пишете его для других :) Архитекторы должны делать свои планы точными, читаемыми и понятными, потому что они знают, что за ними стоит кто-то другой. У них есть инструменты, которые помогают им сделать это. Почему же тогда программисты не делают то же самое? Мы жалуемся, что это «слишком много работы» или «зачем исправлять, что работает?» Правда в том, что не рефакторинг сводится к чистой лени.

Answer 7

Лучше всего использовать согласованный набор правил в команде / проекте, независимо от того, как они применяются (с помощью инструмента CA или проверок кода и т. Д.).

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

Инструменты CA часто делают предложения, которые тратят время (большинство предложений, по моему опыту, довольно мусор). Я имею в виду, что если все члены вашей команды могут эффективно читать, понимать и поддерживать фрагмент кода в том виде, в котором он написан, то часто бывает мало смысла рефакторизовать этот код - опасаясь напрасно тратить время на попытки удовлетворить Resharper, когда изменения Вы делаете, не собираетесь действительно иметь никакого значения для удобочитаемости, ремонтопригодности, надежности, переносимости или эффективности вашего кода. Отключите эти предупреждения, а не тратьте время на рефакторинг вашего кода.

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

Answer 8

Лично я считаю, что стандарты в команде лучше всего работают, если их можно применять и применять с помощью инструмента. Resharper делает хорошую работу (при условии, что вы установили те же правила), давая предупреждения для файлов для форматирования различий. Правила имеют значение только в том случае, если существует инструмент, который их применяет - будь то предупреждения Решарпера или что-то еще, не так важно.

Моя нынешняя команда составляет около половины. Я использую R #, как и пара других участников, но некоторые из нашей команды просто используют VS без него. Однако мы обязуемся соблюдать все стандарты, предоставляемые StyleCop, поэтому пользователи R # довольны (при условии, что у нас установлен StyleCop для Resharper), и пользователи, не являющиеся Resharper, могут работать нормально.