Що робити, якщо колега редагує ваш код лише для зміни зовнішності?

Що робити, якщо колега редагує ваш код?

Без мети додавання функціональних можливостей або виправлення помилок, просто щоб змінити, як це виглядає ...

Поговоріть з ними про це. Зайдіть у розмову зі ставленням: "Вони не роблять цього, щоб мене дратувати або тому, що у них є якась форма обсесивно-компульсивного розладу; вони намагаються вдосконалити мій код".

Тому що ти можеш помилитися. Це може бути витончене виправлення помилок, і ви його просто не помітили.

Або, можливо, існує стандарт кодування, про який ви не знаєте, що ви порушуєте, і вони просто виправляють його.

Або, можливо, вони намагаються вас дратувати, або у них є якась форма нав’язливо-компульсивного розладу. Якщо це так, попросіть їх красиво зупинитися, а якщо це не виходить, візьміть це з вашим начальником.

Але ти ніколи не дізнаєшся, якщо не запитаєш.

Я не такий одружений, як мій код шукає, щоб мене турбувало. :) Я намагаюся вчитися на змінах. Чи мій колега коригував імена змінних? Написати більш ефективний цикл? Зробити код більш читабельним?

Якщо я не бачу, як зміни покращили те, що вже було, я зазвичай запитую у колеги, який вніс зміни, якою була мотивація за ними. Цілком можливо, що перевага мені просто не очевидна. І якщо я маю рацію, і вони помиляються, то, можливо, я можу пояснити, чому я написав це так, як і зробив.

Якщо все інше не вдалося, скасуйте реєстрацію. ;)

Редагувати: все ставки виключаються, якщо бажання зробити косметичні зміни ввели помилку.

IMO ви і ваша команда в будь-якому випадку повинні використовувати стандарт кодування. Якщо це так, то питання стає "Чи відповідає ваш оригінальний код стандарту?" Якщо "так", то ваш колега не повинен торкатися вашого коду, якщо не змінити його функціонально. Якщо "ні", то я боюся, що ваш колега має все право виправити ваш код. Як керівник проекту, я можу постійно це робити.

Якщо ви не використовуєте стандарт кодування, то весь аргумент того, що становить "хороший код", стає занадто суб'єктивним. Отже, чому вам слід використовувати стандарт кодування :)

Як один з цих людей (люди, які періодично переформатують код інших людей), головна причина, яку я роблю, - це читаність. Деякі люди просто надзвичайно неохайні зі своїм відступом або зі змішуванням вкладок та пробілів.

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

Так, я міг би залишити це в спокої, але я би скоріше зменшив розумові зусилля, необхідні для читання коду.

Що з цим робити? По-перше, подумайте, що, можливо, ця людина покращує ваш код. Крім того, ви повинні переконатися, що у вашій команді є певна консенсус щодо того, як слід форматувати код. Якщо у кожної людини різні звички, це сповільнить усіх. Якщо вони не вдосконалюють ваш код і вони йдуть проти зерна, тоді вам потрібно протистояти їм. Якщо це не працює, можливо, вам доведеться залучати інших.

Запитайте їх, чому вони це роблять; дійсне пояснення може зменшити ваше розчарування, але ви повинні дозволити їм знати, наскільки це вас турбує. Хто знає, можливо, вони думали, що роблять вам послугу, і зупиняться, коли дізнаються, що це ображає вас. Або ви можете мати справу з кимось, хто справді страждає від медичного стану.

Чи дозволено йому / йому? Чи зміни покращують код? Якщо так, проковтніть свою гордість. Якщо ви відчуваєте, що якість коду погіршилася, попросіть його співпрацювати і запитайте їх, чому вони відчули необхідність змінити ваш код без очевидних переваг. Якщо це робиться невдало або через те, що людина помилково відчуває, що вони кращі за вас, і ви не можете з ними розібратися, візьміть це з вашим начальником.

IDE, як Visual Studio, має назву, Format Documentяка буде форматувати код відповідно до правил, встановлених користувачем у IDE. Можливо, ваш співробітник використовує це (або автоматично, не знаючи, або шляхом навмисного застосування). Можливо, їх IDE використовує пробіли замість вкладок, або навпаки, і вони застосовуються автоматично, навіть не знаючи? Але вам потрібно поговорити з ними, щоб дізнатися.

До речі, я часто переформатую код колег, якщо він, очевидно, не дотримується якоїсь схеми форматування (тобто він є повсюдно). Це, сподіваємось, тонкий спосіб зробити їх помітними. (Однак я б не переформатував його, якби він був акуратним, але не на свій смак).

Якщо він змінить його так, щоб він відповідав стандартам кодування вашої команди, наступного разу слід дотримуватися стандартів.

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

... У вашій команді є набір стандартів форматування коду, якими користуються всі, чи не так?

Я час від часу переставляю код, написаний безладними колегами (або виправляю помилки в коментарях). Вони знають, що я нав'язливий у форматуванні та порядку коду, і тому дозволяють мені це робити, не надто нарікаючи. Іноді вони також дають мені безкоштовну соду або печиво.

Звичайно, це випадкова робота, оскільки вона порушила функцію "вини" у SVN.

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

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

Я відчуваю, що ти думаєш, що це робити образливо ...? Наприклад, я б негайно виправив цей код

int myFunction( ) {

    int i ;
  return  0;

}

стати

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

так ... чи слід мене покарати через свою дію? У реальному житті я фактично маю тони журналів SVN, які читають "Форматування". ;-)

Використовуйте інструмент перевірки стилю

Почніть використовувати StyleCop або подібні, і застосуйте правила стилю коду, а також покладіть на нього обов'язок усіх розробників використовувати його. Весь код буде без винятку виглядати однаково. І збирайтеся разом з розумними головами, щоб обговорити найбільш підходящі правила для вашої організації. Навіть незважаючи на те, що правила за замовчуванням вже дуже схожі на сам .net рамковий код.

Це найпростіший спосіб зробити це. Я виявив, що виправляю чужий код у одного з моїх попередніх роботодавців, тому що цей інший хлопець писав код із надмірною кількістю порожніх рядків і жодних правил відступу. Код насправді непрочитаним середнім розробником. Якби StyleCop існував ще тоді, це зробило б багатьох із нас справді щасливими.

це думка, яку я бачив в Інтернеті, розмовляючи про рефакторинг, і, можливо, пояснюю, чому хтось торкнеться вашого коду, щоб зробити це краще:

Чому?

Існує дві основні причини рефактора:

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

2. Пристосовуватися до змін вимог. Зміни відбуваються при розробці програмного забезпечення; щоб реагувати на зміни, краще мати гарну базу коду. У нас є два варіанти для обох сценаріїв, відстежувати код або рефактор. Виправлення коду призведе нас до нездійсненного коду, і збільшить наш технічний борг, завжди краще робити рефактор.

Коли?

1. Чим швидше, тим краще.

2. швидше і менш ризиковано перетворювати рефактор на нещодавно реконструйований код, а не чекати, коли рефактор буде майже завершеним.

Що?

1. Весь код і вся конструкція є кандидатами на рефакторинг.

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

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

ура