Чи корисно відформатувати код у затемненні, використовуючи автоматичний формат


20

Я використовую eclipse для кодування, а мова, якою ми користуємось, - Java. Колись хтось запропонував правильно форматувати код, використовуючи автоматичний форматів (CTRL + SHIFT + F) Хоча ця команда форматує код, але іноді я відчуваю, що загальний вигляд стає дивним, і він насправді не дуже читабельний.

Так це рекомендується робити? Якщо ні, то що краще від форматування нашого коду в затемнення?


Я весь час використовую потенціал автоматичного форматування Emacs - є потенціали для зіткнень (наприклад, з об'єднанням SC) .. але загалом стандартизація вашого формату дуже корисна
warren

Відповіді:


34

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

Eclipse (або будь-який хороший IDE для цього питання) має правила форматування коду, які можна налаштувати в розділі налаштувань (Java> Стиль коду> Форматтер). Виберіть те, що вам найбільше подобається, але також ознайомтеся зі стандартними умовами коду Java . Багато проектів з відкритим кодом також мають власні конвенції про коди, які можна застосовувати за допомогою форматора Eclipse.

Крім того, існують стандартні інструменти, такі як CodeStyle, PMD та Findbugs, які застосовують додаткові правила та допомагають уникнути поширених анти-шаблонів (помилок) та помилок.


4
Після того, як ви налаштуєте свій форматер так, як вам це хотілося. Існує кнопка "Експорт", яка дозволить вам зберегти її у .xml файл. Ми розміщуємо це у нашому сховищі SVN, тому кожен має доступ до нього, коли перевіряє проект.
Кріс

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

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

24

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

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

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

// @formatter:off

... my nicely formatted table here ...

// @formatter:on

5
+1: я ніколи не знав про (або якщо бути точнішим, я ніколи не намагався дізнатися про) теги включення / вимкнення.
Пол Кагер

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

@Mufasa Так, ти маєш рацію.
JesperE

1
Якщо ви не хочете коментувати формат, ви можете написати / * - мій суперформат * / Eclipse не форматувати такий коментар :)
Dawid Drozd

5

Чи рекомендується це чи ні, залежатиме від того, кого ви запитуєте.

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

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

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

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


5

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

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

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


0

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

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

Кожна нова версія Eclipse може змінити формат (в кращу сторону), але внесе суттєві зміни, такі як JavaDocs остаточно видалить цей додатковий простір після, *але введений десь після того, як Helios та багато підприємств використовують старішу версію раціонального програмного забезпечення eclipse що використовує Геліос як базу.

Форматор коду, який надається Eclipse, не розширюється відповідно до їх API, адже він прямо заявляє CodeFormatter javadoc

Цей клас не призначений для підкласи клієнтів.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.