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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

int myFunction( ) {

    int i ;
  return  0;

}

становиться

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

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

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

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

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

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

Почему?

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

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

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

Когда?

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

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

Какая?

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

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

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

ура