Должен ли я использовать Resharper, чтобы привести в порядок код других людей?

Question

Я использую Resharper на работе. Некоторые из моих коллег этого не делают.

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

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

Полагаю, я вижу свои варианты как

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

2) Измените бессмысленные вещи, такие как include, исправьте комментарии к документации метода и тому подобное. Парню, который написал это, нравится, что его код выглядит так, поэтому оставьте его в состоянии, когда он не будет жаловаться, но избавится от некоторых ненужных оранжевых

3) Оранжевый просто красный, но светлее. F12, затем Alt + Enter до зеленого цвета.

4) Забудьте об апельсине, посмотрите на функцию монстра на 700 линий. Что это за 1997? Пора заняться делом ... и, если у вас есть время, представьте своего коллегу нашему хорошему другу и наставнику мистеру Фаулеру.

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

Похоже, что один из 4 вариантов должен быть тем, к которому я стремлюсь, но я не знаю, какой

Answer 1

"Leave the campsite cleaner than you found it."

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

Answer 2

Ваша команда должна согласовать стандарт. Если кто-то еще использует другой инструмент, вы можете оказаться в непреднамеренной войне правок.

Но если вы все согласны, тогда да. Очистите код на ходу.

Answer 3

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

Answer 4

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

Если «бессмысленные» материалы (документация, комментарии и т. Д.) Должны быть отформатированы определенным образом, и это не соответствует вашим стандартам разработки, то я бы сделал все сразу, как можно меньше.

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

Answer 5

Я рекомендую менять вещи только тогда, когда это необходимо. Конечно, существует определенное определение того, что означает «необходимость». Например, если вы пишете метод, который вызывает другой метод, и этот метод, который вы вызываете, имеет некоторое дублирование кода? Я бы реорганизовал это, и пока я в нем удаляю лишние операторы using и т. Д. Я бы попытался избежать просто масштабного рефакторинга всей кодовой базы «просто потому, что».

Answer 6

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

Answer 7

Если инструменты разработки в вашей команде не совпадают, то в конечном итоге возникнут еще большие проблемы. Выполните регистрацию «переформатирования», предложенную выше, и стандартизируйте набор инструментов с вашими коллегами, либо бросьте резарпер, либо раздайте всем волшебную палочку форматирования.

Answer 8

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

Рефакторинг помогает всем стать лучше, и у всех должен быть доступ к инструментам рефакторинга (Coderush для меня).

Однако, если ваши коллеги не разделяют любовь к рефакторингу, то это хорошая возможность для вас просветить их:)

Answer 9

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

Answer 10

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

В общем, я приведу в порядок стили кода, чтобы привести его в соответствие с заявленными целями стиля организации, когда коснусь кода по другой причине. Однако помните, что стиль есть стиль, и как такового не существует «единственно верного пути». Не создавайте врагов, потому что вам не нравится тот факт, что коллега использует меньше (или больше) пробелов, чем вы.