Було б поганою ідеєю періодично запускати формати коду у сховищі?

Я думаю створити роботу cron, яка перевіряє код, запускає на ньому формати форматів, і якщо щось змінилося, здійснює зміни та відштовхує їх назад.

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

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

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

Крім того, ви хочете переконатися, що ці зміни нічого не порушують. Наприклад, у нас є правило, яке впорядковує властивості та методи в алфавітному порядку. Це може вплинути на функціональність , наприклад, на порядок даних та методів у файлах WSDL договорів WCF.

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

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

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

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

Я не запускатиму їх періодично, але, якщо можливо, до початку контролю версій.

За допомогою git , гачок , який попередньо здійснює , буде корисним. У багатьох проектах C або C ++, побудованих за допомогою Makefile , я додаю деяку indentціль (яка запускає відповідні формати коду, як-от indentабо astyle) і очікую make indentрегулярного запуску дописувачів . До речі, ви можете навіть додати деякі makeправила, щоб переконатися, що гачки git були встановлені (або для їх встановлення).

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

Контроль версій - це здебільшого певний інструмент для сприяння спілкуванню між розробниками людини (включаючи власне «я» через кілька місяців) Програмному забезпеченню не потрібно VC або форматування, але ваша команда робить.

BTW, різні спільноти та різні мови програмування мають різні погляди на форматування коду. Наприклад, у Go є лише один стиль форматування коду, але у C або C ++ їх дуже багато.

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

Кращим підходом було б включити інструмент перевірки формату у свій інструмент побудови. (На Java існує Checkstyle ) Потім дозвольте людям об'єднати свої гілки до головної гілки, якщо збірка проходить (включаючи форматування).

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

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

Так само, як і рекомендація @ BasileStarynkevitch, ми використовуємо гачки на стороні сервера, що надсилаються на сервер, щоб надсилати "рекомендаційні електронні листи" щодо стилю коду.

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

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

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

Як говорить @DocBrown, інший варіант - застосувати стиль коду у вашому IDE. Ми використовуємо CodeMaid з Visual Studio для виправлення багатьох поширених помилок стилю. Він буде працювати при збереженні файлів коду, тобто код поганого стилю ніколи не повинен перетворювати його на репо ... теоретично :-).

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

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

Я не хочу перевіряти це зараз на роботі, але ви повинні спробувати це самостійно.

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

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

Натомість ви потенційно можете вкласти це у нічний або тижневий.

Але навіть нічна може бути поганою ідеєю.

Ви можете або запускати її щотижня, коли ви впевнені, що конфліктів злиття не виникне, оскільки все закінчено в понеділок.

В іншому випадку запустіть його 1-2 рази на рік у сезон відпусток, коли конфліктів злиття не буде.

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

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

Або ви можете включити скрипт налаштування гака у папку для своїх розробників у проекті та просто перевірити його в самому git.

Щось я не бачив, це те, що іноді є законні причини не відформатувати щось відповідно до набору правил. Іноді чіткість коду поліпшується, якщо суперечити заданому керівництву, що 99% часу має сенс. Люди повинні здійснити цей дзвінок. У таких випадках автоматичне форматування коду закінчується, роблячи речі менш читабельними.

Це жахлива ідея.

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

Якщо ви хочете робити це регулярно, це просто жахливо.

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

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

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

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

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

Один з варіантів - встановити псевдонім (або гачок, або будь-який інший) функції фіксації, який запускає форматформа коду на коді, який повинен бути скоєний, перш ніж він буде вчинений.

Він може мати 2 (або більше) результатів:

1) Покажіть користувачеві запропоновані зміни та попросіть їх схвалення застосувати та вчинити зміни.

2) Ігноруйте запропоновані зміни та виконайте початковий код.

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

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

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

Приємно, що він є частиною проекту, тому кожен розробник отримає його за свій проект.

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

Огляди коду запобігають будь-яким помилковим.

Ще одне місце я би зробив це, щоб це було частиною побудови. У моєму випадку я маю таке, що maven build буде переформатувати XML та очистити пом-файли та переформатувати код.

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