Чи нав'язувати однаковий формат коду для всіх розробників гарною ідеєю?

Ми розглядаємо можливість нав'язати єдиний стандартний формат коду в нашому проекті (автоматичний формат із збереженням дій у Eclipse). Причина в тому, що в даний час існує велика різниця у форматах коду, які використовуються декількома (> 10) розробниками, що ускладнює роботу одного розробника над кодом іншого розробника. Один і той же файл Java іноді використовує 3 різних формати.

Тому я вважаю, що перевага очевидна (читабельність => продуктивність), але чи було б гарною ідеєю це нав'язувати? А якщо ні, то чому?

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

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

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

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

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

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

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

Багато розробників програмного забезпечення ведуть євангельські війни ......

Залежно від вашої позиції в команді та динаміки команди, ви можете вирішити, що виграти війну неможливо. У цьому випадку, можливо, найкраще не починати ...

Так, добре мати один стиль формату коду для всіх розробників.

Розробіть формати стилів коду та імпортуйте їх до всіх затемнень розробників.

Це допоможе, коли ми будемо mergingкодовані до системи «Версія контролю».

Що ви намагаєтеся отримати, наскільки анальний утримувач ви будете виконувати його (і на рівні деталізації будуть викладені ваші "правила"), чи будете ви намагатися застосувати його за кодом, написаним різними мовами, Ви збираєтесь спробувати застосувати його заднім числом на існуючому коді?

1. загальний зовнішній вигляд коду дійсно може допомогти зробити код більш читабельним, але також може погіршити ситуацію, якщо це неправильний вигляд. Примітка _hUngarian_lpfstr є головним прикладом :)
2. Я бачив "стандарти коду", що застосовують кількість пробілів між пробілами в блоках коментарів, алфавітне впорядкування назв методів та інші дурниці. Не робіть цього.
3. Різні мови мають різні стандарти, до яких звикли люди, які мають досвід їх використання. Деякі навіть призначають ці стандарти (думаю, що Python, Cobol, Visual Studio автоматично накладають умови зміцнення стилю C ++, тоді як Java використовує стиль C за умовами і т.д. тощо).
4. ніколи не змінюйте існуючий код заради його зміни, ви лише таким чином вводите нові проблеми. А це означає розділи коду, а також цілі вихідні файли. Тому не обмінюйте переформатування існуючого коду, коли хтось змінює один рядок у файлі 1000 рядків.
5. досвідчені програмісти можуть бути набагато продуктивнішими, якщо їм не доведеться думати вдвічі, чи буде те, що вони пишуть, "правильно виглядати" в системі автоматичного затвердження або в рецензері. Вони також мають звичку писати чистий код просто тому, що це працює, навіть якщо між їх природними стилями є невеликі відмінності.

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

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

Я просто хотів додати пару пунктів, які не використовувались ніде:

• Oracle опублікував набір конвенцій для Java, які є фактичним стандартом.
  • Використовуючи ці, слід допомогти вам уникнути аргументів щодо того, якого стилю слід дотримуватися.
  • Багато публічних бібліотек та проектів з відкритим кодом, як правило, використовують ці конвенції, тому, коли вам потрібно переглянути ці формати, слід знати.
  • Форматор Eclipse має вбудовані правила для відповідності цим умовам, що також повинно допомогти.
• Можливо, ви захочете розглянути можливість створення гачка в налаштуваннях керування джерелом, щоб код набув автоматичного форматування, перш ніж він потрапить у головну гілку.
  • Ви можете уникнути битв з особливо впертими програмістами, які відмовляються дотримуватися стандарту. Вони навіть можуть використовувати своє власне форматування під час роботи, яке згодом стане стандартизованим!
  • Якщо ви користуєтесь налаштуваннями форматування (наприклад, багато людей ігнорують конвенцію "не більше 80 символів на рядок"), вам доведеться вносити зміни лише в одному місці.

Я був у команді, яка використовувала плагін Checkstyle . Замість використання нестандартних функцій ми створили невеликий комітет зацікавлених розробників. Ми обговорювали те, що здавалося відсутнім, що здалося надмірним, і вибивали речі. Ми всі чомусь навчились і зміцнили ці м’язи розробника.

(Приклади наших рішень: ширина 72 символів занадто мала, але 120 краще; краще використовувати _ALLCAPS для статичних фіналів; примусове використання єдиного виходу з функції - хороша ідея.)

Коли у нас були огляди коду, одне з перших запитань було: "Ви провели це через Checkstyle?" Дотримання стандартів кодування значною мірою було автоматизовано, і це звернуло увагу на те, щоб рецензент не був вибагливим. Надзвичайно легко було Checkstyle виділити метод підпису, клацнути правою кнопкою миші та змінити змінну на остаточну. Він також міг би виправити відступи та дужки, щоб код кожного мав подібний вигляд та відчуття. Відсутній Javadoc для публічної функції? Контрольний стиль позначить функцію.

(Видалення запаху коду важливіше, ніж послідовне форматування. Це перевага автоматизованих інструментів.)

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

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

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

Особисті переваги є саме цим і рідко покращують виробництво: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Якщо це трапиться, перейміть його і щось зробіть.

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

1. Машина помиляється в найгірший можливий час, і зазвичай, коли ви використовуєте нову мову. Як він буде обробляти закриття в Java тощо? У Джалопі виникають проблеми з перерахунками з функціями членів.
2. Я думаю, що на програміста дуже покладено тягар, щоб він видав код компанії, схожий на код компанії. Я вважаю за корисне зазначити, що саме так форматується код "тут", а не як весь код повинен бути форматований скрізь. Моя попередня компанія, можливо, обрала інший шлях, і це нормально. На відміну від простомовної мови, існують ідіоми, характерні для вашої культури коду, які ви хочете вивести.
3. Забезпечення синтаксису коду найкраще проводити з огляду коду:
   1. Якщо форматування важливе, то воно змушує вашу організацію перевіряти код. Це має величезну користь.
   2. Якщо правило форматування порушено, людина може подивитися на це і судити краще, ніж машина, якщо наміри передаються більш чисто. Це дуже рідко, але трапляється зрідка.

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

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

Я думаю, темою цієї відповіді є: Перегляньте код і нехай форматування випливає з культури та поза процесом огляду.

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

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

Однак, більш жорстке правило "дотримуйтесь конвенції коду, яка вже існує у файлі / проекті" є хорошим.

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

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

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

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

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

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

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

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

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

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

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

Один формат, щоб керувати ними всіма ... це справді оптимально?

Це як водіння чужого автомобіля ...

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

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

+1 до всіх пільг, згаданих до цього часу, але ...

Автоматичне примусове виконання вимагає витрат, які потрібно враховувати:

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

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

Мають правила форматування, але дозволяють певну свободу застосовувати здоровий глузд.

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

Правило 1: Наведіть змінні / курсори / об'єкти / процедури / будь-які ЧИСЛІ ІМЕНИ. Однозначні імена, які приносять значення та розуміння вашому коду.

Правило 2: Використовуйте відступи, щоб показати структуру вашого коду.

Це воно.

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

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

Компанія Google опублікувала документ про це під назвою "Пошук боргу зі збірки: досвід управління технічним боргом у Google" .

Це мови, а не коди. Ми, люди, маємо понад 6000 мов, тому ми їх перекладаємо. Тож якщо ви хочете, щоб ваші "коди" повідомляли, вам доведеться внести свої корективи. Ви бачите, що ми повинні змінити формати даних, щоб ми не втратили свої дані.

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

Мої найбільші проблеми з цією концепцією

1. Якщо я пишу код в одному форматі, і він автоматично переформатується, який стимул може насправді вивчити цей формат?
2. Після цього попереднього пункту, якщо ви не вивчите формат, вся точка автоматичного форматування (щоб зробити код легше читати і змінювати) повністю втрачається. Вам все-таки знадобиться час, щоб розібратися у форматуванні під час читання коду, оскільки ви його ще не вивчили
3. Я думаю, що було б неприємним досвідом, як розробник, щоб написати один день клас, закрити його і повернутись наступного дня, щоб побачити, що це зовсім інше. Це означає, що не тільки інші повинні вивчати ваш код, ви повинні вивчити свій код.
4. Це також може стимулювати ліниве кодування. Замість того, щоб підштовхувати розробник до вивчення формату, вони можуть писати у будь-якому форматі під сонцем, і це автоматично виглядатиме так, як хочуть усі інші. Це повертається до №2, де ви не вивчаєте стиль і все ще не можете його правильно прочитати.

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

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