Форматування коду погано при використанні VCS?

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

Нещодавно я встановив електроінструменти VS, який має опцію "Форматувати при збереженні", і вніс зміни до файлу, який раніше не був відформатований. VP розробник просто прийшов до мене і дорік мені за форматування, оскільки в інструменті злиття виявляється, що майже весь файл змінився замість просто рядка або двох (тож він не може точно бачити, що я легко змінив), і сказав мені відключити формат збереження в майбутньому. Хоча я розумію це занепокоєння, мені буває важко іноді розбирати код, який неформатований, і IMO його слід форматувати належним чином у будь-якому разі. Зауважте, що я не просто переформатую речі на примху. Але, коли я пишу код, я або використовую електроінструмент, або натискаю клавішну команду, щоб відформатувати текст, щоб його було легше читати, і в SVN це відображається як модифікація.

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

По-перше, вашій команді потрібно вибрати конвенцію про форматування та дотримуватися її. Потрібно домовитись, щоб усі дотримувалися цього, щоб у вас не було людей, які б'ються за те, як слід виглядати. Це не повинно бути лише тим, що ви робите самостійно.

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

Ні, форматування коду дуже важливо . Однак комісії слід здійснювати у двох групах:

1. Косметичні зміни - все, що робить код більш читабельним.
2. Інші зміни - все інше, що впливає на код.

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

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

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

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

• Очистіть форматування лише навколо зміненого коду. Якщо ви внесете зміни лише до однієї функції, тоді очистіть цю функцію. Принаймні з часом у вас з’явиться кращий вигляд коду.

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

• Отримайте хороший інструмент розрізнення, який може робити мовне залежність від значущих змін та несуттєвих змін. Моя улюблена різниця За межами Порівняти відмічає фактичні зміни коду в одному кольорі, а пробіли / коментарі - лише відмінності в іншому.

відредагуйте ще одну пораду:

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

Ви не повинні переформатувати та вносити зміни до коду інших людей, якщо:

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

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