Чи є якась користь від одержимості створення коду "виглядати красиво"?

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

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

Я просто буду повністю OCD або в цьому є якась користь?

Використовуйте автоматичний форматник. Якщо ви дійсно витрачаєте стільки часу вручну на редагування коду, я б хотів здогадатися, що ви не дуже кидаєте виклик / нудьгуєте, оскільки для цього абсолютно немає причин. Ctrl + K, Cntrl + D у VS буде форматувати весь документ. Ви можете використовувати щось на зразок Style Cop, якщо хочете дещо більш важкої ваги.

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

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

Нічого прихованого, гарний код легко читати і легко обслуговувати.

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

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

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

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

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

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

Колись комусь доведеться підтримати ваш код. Чистий код підтримувати набагато простіше. І якийсь день, що ти може бути. Через 6 місяців чи рік ти не пам’ятатимеш, що робив. Але якщо він чистий і легкий для читання, він швидко повернеться.

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

Ні - одержимість того, щоб код виглядав красиво, не вистачає сенсу .

Ось кілька частин мудрості, які я вважаю корисними:

Запитайте, чому для коду потрібно бути охайним.

Ви можете або не можете витрачати свій час залежно від вашого визначення досить.

Фундаментальна теорема форматування говорить, що хороша візуальна компонування показує логічну структуру програми. Зробити гарний вигляд коду варто щось, але варто менше, ніж показати структуру коду. [pg 732, Code Complete 2nd Edition, Steve McConnell]

Якщо ви використовуєте систему одночасних версій для відстеження змін у коді - не змішуйте зміни форматування коду з логічними / додаваннями змін змін у межах одного комітету.

Це зробить зміни складніше і спричинить непотрібні конфлікти злиття, якщо інші члени команди редагують файл. Якщо вам потрібно внести зміни форматування, перевірте, чи інші члени команди не працюють над цим файлом. [Перефразоване, стор. 93, прагматичний контроль версій за допомогою Subversion, 2-е видання]

Також Мартін Фаулер розповідає про "носіння двох шапок" та перемикання між ними протягом дня. Одна шапочка для додавання функцій, одна шапка для рефакторингу.

1. Ви можете розглянути можливість додавання нової функції (Feature Hat)
2. Ви вивчаєте наявний код, щоб отримати розуміння, прибираючи в дорогу. (Капелюх рефакторингу)
3. Здійснити зміни.
4. Додайте функцію. (Характерний капелюх) тощо.

[Перефразував стор. 57, Рефакторинг, Мартін Фаулер]

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

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

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

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

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

Ви повинні створити чистий код, але це не повинно зайняти годин.

Для C є gnu-програма gnu-indent gnu-indent , у затемненні є принаймні кодовий формат для Java, і я думаю, є інструменти і для більшості інших мов. Для правильного відступу файлу потрібно декілька клацань, і якщо ви хочете порушити правила для певних цілей - як це я роблю для коротких заяв про переключення випадку:

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

що важко вказати.

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

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

http://www.joelonsoftware.com/articles/Wrong.html

Зокрема цей список:

Гаразд, поки що я згадав про три рівні досягнення як програміст:

1. Ви не знаєте чистого від нечистого.

2. Ви маєте поверхневе уявлення про чистоту, переважно на рівні відповідності умовам кодування.

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

Однак є ще вищий рівень, про що я дійсно хочу поговорити:

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

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

"Години"? Ну, я б сказав, що ваша відповідь "і", а не "чи": так, ви є OCD, але в цьому є якась користь.

Мабуть.

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

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

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

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

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

Ви розпізнаєте проблему (компульсивна поведінка) та симптом (форматируемое нав’язливо).

А як щодо причини та лікування?

• Ви працюєте занадто багато годин?
• Ви розчаровані, нудьгуючі, тривожні?
• Яке ваше наступне завдання? Це щось, чого ти не хочеш робити?
• Коли ви востаннє відпочивали? Акція? Визнання за досягнення?
• Це питання, пов'язане з вигоранням?
• Ви на Марші смерті?

Іноді ці симптоми є ознакою того, що пора вносити сміливі зміни або рухатися далі.

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

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

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

Тепер дайте собі дозвіл діяти на це.

Святий Божо!
Ви ніколи не чули відступ?

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

ermm - але він працює лише на C і деяких, але не на всіх C ++ .... (wtf? чому GNU не оновить його?)