Что делать, если сотрудник редактирует ваш код, чтобы изменить внешний вид?

16

Что делать, если сотрудник редактирует ваш код?

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

Тамара Вийсман
источник
9
Я полагаю, у вас есть проблемы с этим. Если так, то почему? Это делает код хуже ?
Заз
3
@Josh: Да, на самом деле, он делает код хуже, потому что его поддерживает другой программист, а не тот, кто его написал.
Роберт Коритник
4
дать ему больше работы
Оскар Кабреро
4
@ Роберт - Я думаю, что ты упустил точку зрения Джоша. Изменение внешнего вида кода может объективно облегчить поддержку ... особенно, если он изначально был плохо отформатирован.
Стивен С
4
Это действительно ваш код или он принадлежит команде?
Эрик Кинг,

Ответы:

28

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

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

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

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

Но вы никогда не узнаете, если не спросите.

BlairHippo
источник
17
Стоит отметить, что многие IDE имеют функции автоматического форматирования. Я использую их все время, не думая об этом. Некоторые даже отформатируют все файлы в вашем проекте или все файлы, которые вы открыли, в зависимости от того, как он настроен. Это может быть легко случайно автоматически форматировать.
Мэтт Оленик
@Matt: Отличная мысль.
BlairHippo
1
«Они этого не делают ... потому что у них есть какая-то форма обсессивно-компульсивного расстройства»; Говоря в первую очередь о себе, это не всегда так! Когда дело доходит до кода, я две вещи: перфекционист и аккуратный урод. Несмотря на это, я обычно стараюсь не применять этот менталитет в работе моих коллег.
Натан Тейлор
5
О, я не говорю, что коллега Тома НЕ ОКР-урод с плохим чувством границ. Я просто говорю, что вступаю в разговор с мыслью: «Что, черт возьми, С тобой не так ?!» не хороший способ вести продуктивный разговор. :-)
BlairHippo
1
@ Крис, не нужно беспокоиться об оправдании, я всегда Ctrl + K + D!
Натан Тейлор
16

Я не настолько женат на том, как выглядит мой код, чтобы беспокоить меня. :) Я стараюсь учиться на изменениях. Мой коллега корректировал имена переменных? Написать более эффективный цикл? Сделать код более читабельным?

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

Если ничего не помогло, отмените регистрацию. ;)

Изменить: Все ставки отключены, если желание внести косметические изменения привело к ошибке.

Адам Лир
источник
9

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

Если вы не используете стандарт кодирования, тогда весь аргумент того, что составляет «хороший код», становится слишком субъективным. Следовательно, почему вы должны использовать стандарт кодирования :)


источник
8

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

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

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

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

Дэн Дайер
источник
Это ваша читабельность, я считаю, что неиспользуемый код SQL намного легче читать, потому что я читаю быстро, а код с отступами замедляет меня и затрудняет фокусировку.
HLGEM
6

Спросите их, почему они это делают; правильное объяснение может уменьшить ваше разочарование, но вы должны сообщить им, насколько это вас беспокоит. Кто знает, может, они думали, что делают вам одолжение, и остановятся, когда узнают, что это вас обижает. Или вы можете иметь дело с кем-то, кто действительно страдает от заболевания.

JeffO
источник
«Или у них ОКР, и им может понадобиться лекарство». - лучше не упоминать эту часть, если вы хотите остаться дружелюбным
Zaz
Я внесу поправку.
Джефф
5

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

Чинмай Канчи
источник
5

В IDE, как и в Visual Studio, есть опция, Format Documentкоторая будет форматировать код в соответствии с правилами, установленными пользователем в IDE. Это может быть ваш коллега использует это (либо автоматически, не зная, либо по преднамеренному применению). Возможно, их IDE использует пробелы вместо вкладок, или наоборот, и они применяются автоматически, даже не зная? Но вам нужно поговорить с ними, чтобы узнать.

Между прочим, я часто буду переформатировать код сотрудников, если он явно не следует какой-то схеме форматирования (то есть он везде). Это, надеюсь, тонкий способ заставить их заметить. (Однако я не переформатировал бы это, если бы это было опрятно, но не по моему вкусу).

Дэн Диплом
источник
1
«(Однако я бы не переформатировал его, если бы он был аккуратным, но не по моему вкусу)» - очень важное правило,
которому
Наши руководящие принципы разработки, как правило, ставят стиль кода больше в «рекомендуемый» угол. Я автоматически форматирую код в соответствии с рекомендациями на уровне файлов, если мне трудно читать.
Джори Себрехтс
3

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

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

... У вашей команды есть набор стандартов форматирования кода, которые используются всеми, верно?

Daenyth
источник
2

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

Конечно, это случайная работа, поскольку она сломала функциональность «вины» в SVN.

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

Wizard79
источник
2

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

Илья К.
источник
1

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

int myFunction( ) {

    int i ;
  return  0;

}

становиться

int myFunction() {
    int i;
    return 0;
}

так ... я должен быть наказан за мои действия? В реальной жизни у меня есть тонны журналов SVN, прочитанных «Форматирование». ;-)

ТИА
источник
0

Используйте инструмент проверки стиля

Начните использовать StyleCop или аналогичные и применять правила стиля кода, а также обязать всех разработчиков использовать его. Весь код будет выглядеть одинаково без исключения. И соберитесь с умными руководителями, чтобы обсудить наиболее подходящие правила для вашей организации. Хотя правила по умолчанию уже очень похожи на сам код .NET Framework.

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

Роберт Коритник
источник
Я должен проголосовать против. StyleCop - ужасная реализация достойной идеи. 1) Он запускается после сборки, что делает его основным убийцей времени в больших проектах. 2) Это стандартные правила, в некоторых случаях противоречащие настройкам VS по умолчанию. 3) Некоторые из правил являются чисто бессмысленными. Он жалуется на «//» без завершающего пробела, а затем говорит вам использовать «////» снова после сборки. Это худшая часть. Это было бы неплохо, но часть после сборки действительно убивает вас в большом проекте с длительным временем сборки.
МВД
Я бы не согласился с вами по многим аспектам, на которые вы указали. Вы можете настроить способ проверки стиля. Я даже реализовал пару своих собственных правил, которые обеспечивают форматирование, которое я хочу. Что касается скорости, я не могу сказать, что это здорово. но на приличной машине все должно работать просто отлично. Подумайте только о скорости работы C ++ в начале 90-х, когда вы действительно смогли приготовить чашку чая. Пока ваша сборка не удалась !!!!!! ;)
Роберт Коритник
Я только начал использовать StyleCop, чтобы увидеть, как он работает, и, хотя иногда он немного раздражает, он также помогает находить множество ошибок, которые в противном случае остались бы незамеченными. Вам не нужно запускать его как часть сборки, и вы можете просто запустить его на своем локальном компьютере, также только для отдельных файлов. Таким образом, вы можете использовать его, не раздражая ваших коллег-разработчиков. Плюс, если вам не нравятся правила, вы можете просто отключить их, так что никакого реального вреда не будет.
Анна Шуесслер
+1 Это явно не о StyleCop .. (StyleCop или подобное ). И это очень хорошая идея. Определите набор правил, настройте свой инструмент выбора и будьте с ним навсегда.
Бруно Шэппер
В наши дни у нас есть Grunt, Gulp и т. Д., Которые могут сделать этот шаг точно так же, как это делал StyleCop в прошлом.
Роберт Коритник
0

эту мысль я видел в интернете, говоря о рефакторинге, и, возможно, объясню, почему кто-то трогает ваш код, чтобы сделать его лучше:

Почему?

Есть две основные причины рефакторинга:

  1. Чтобы улучшить код / ​​дизайн, прежде чем строить на его вершине: очень сложно придумать хороший код с первой попытки. Первая попытка реализовать любой первоначальный дизайн покажет нам, что мы неправильно истолковали или забыли какую-то логику.

  2. Адаптироваться к изменениям требований. Изменение происходит в разработке программного обеспечения; Быть отзывчивым на изменения лучше иметь хорошую базу кода. У нас есть два варианта для обоих сценариев: путь к коду или его рефакторинг. Патчирование кода приведет нас к не поддерживаемому коду и увеличит наш технический долг, всегда лучше проводить рефакторинг.

Когда?

  1. Чем скорее, тем лучше.

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

Какая?

  1. Весь код и весь дизайн являются кандидатами на рефакторинг.

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

Вы просто должны позволить ему сделать все возможное, если это будет здорово для обоих и сэкономить ваше время в будущем!

ура

Младший М
источник