Ви справді пишете "чистий код"? [зачинено]

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

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

Отже, скільки ви насправді пишете «чистий код»? Це хороша практика? Які ще є переваги чи недоліки цього?

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

Мені пригадується запис у блозі Джоела Спольського: Програміст стрічки .

Він цитує « Кодери на роботі» :

Зрештою, відправте річ f ***** g! Чудово переписати свій код і зробити його більш чистим, а втретє він буде справді гарним. Але це не сенс - ви тут не для того, щоб написати код; ти тут, щоб відправляти товари. - Джеймі Завінський

Мені також нагадується відповідь блогу Роберта Мартіна :

Тому. Бути розумним. Будьте чисті. Будь простий. Корабель! І тримайте невеликий рулон клейкої стрічки в готовності, і не бійтеся його використовувати. - Дядько Боб

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

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

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

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

Але ви говорите про over styling(на кшталт цього терміна, краще, ніж дівчина-код ), який служить не що інше, як его его автору.

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

Це занадто.

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

Я не погодився б із прийнятою відповіддю на це питання.

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

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

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

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

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

Чому це має бути різним для частини програмного забезпечення?

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

Відповідаючи на запитання "Чи справді ви пишете" чистий код "?" -- О так.!

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

Чорт так.

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

Чесно кажучи, це залежить. Мені подобається, як всі вискакують партійну групу про те, як «що-небудь менше, ніж чистий добре задокументований код, є чистою травестією!», Але я працюю в бізнесі зі смішними циклами розгортання та нульовим наглядом: я роблю все можливе, але пишу так багато коду, надзвичайно важко написати чистий ідеальний код, який всі інші стверджують, що вони пишуть.

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

Іноді я відчуваю трохи провини в цьому, але не дуже. Ви повинні побачити деякі страхіття, з якими я стикаюся щодня. Десятиліття користувацького коду на незрозумілих мовах з нульовою документацією. Один з моїх колег розвивається виключно у Visual Basic 6.0 і розкриває скрізь криптично названі двійкові файли. Жінка, яку я замінила, програмувала виключно в RPG .

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

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

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

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

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

Тоді я дозволяю ReSharper зробити це «гарним кодом» для мене (наприклад, вирівнювання, розрив рядків тощо). Є гарне значення в написанні гарного коду. Але є зменшення віддачі. Деяка попередня обробка робить її трохи більш досяжною завдяки простоті читання.

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

Якби у мене не було ReSharper, у мене все-таки був би чистий код, але він був би не таким гарним.

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

Здається, ніхто не піднімає питання про те, що найбільше цікавить вашу компанію?

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

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

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

Аргументом може бути "Чому я повинен розпродавати і писати банальний код?". Ну чому б ваша компанія платила вам гарний чек щомісяця? Вибори, мій друже. Якщо ви після ідеалізму, спробуйте Фонд вільного програмного забезпечення ; Я чую, що вони роблять якісь цікаві речі (я маю на увазі це, і я поважаю FSF та OSS).

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

Програмісти люблять «чистий» код, що б це не означало. Ми навіть не можемо домовитися про те, що є чистим, але ми це любимо. Однак іноді це просто не так важливо, як зручність та правильність. Вони можуть здатися синонімами, але це не так - якщо ви побачили код, написаний справжнім хакером Perl за 4 години з наміром використовувати два рази та викинути, ви визнаєте, що це не чисто, але це працює.

Тож іноді, убік его, ми мусимо просто працювати. Зауважте, що я не рекомендую писати поганий код як звичку; Я просто вказую, що це може знадобитися. Для вдосконалення потрібен час, який ваша компанія може не мати. Отже, якщо ваш роботодавець не проти, програмне забезпечення для крафт, але якщо вам потрібно, просто напишіть робочий код, не забувайте про «чистоту». Це просто не відповідь "Один розмір, який відповідає всім" - вам слід надати пріоритет.

Я не впевнений, що "добре виглядати" та бути "елегантним, ідеально зрозумілим та ремонтопридатним" - це рівнозначно.

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

Я не бачу жодних недоліків, за винятком отриманих витрат у часі.

Щоб код "добре виглядав", існує безліч автоматизованих інструментів, які належним чином відступ і простір все, що ви хочете.

Занадто багато всього ніколи не буває корисним.

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

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

Це цитата Боб Мартіна з чистого коду:

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

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

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

Мені подобається читати код, але найголовніше - це послідовність. Для мене це означає узгодженість конвенцій іменування та проміжки між функціями, дужки в одному рядку або наступний рядок оператора if і т.д.

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

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Ну ... Це виглядає гірше з методами Objective-C і з безліччю і безліччю вкладених, якщо заяви і рядки набагато довші за 80 символів. Але це все одно мене дратує :)

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

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

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

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

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

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

Це фрагмент коду, що демонструє мій стиль кодування.

Просто уникайте "коду марнославства". Є багато розробників, які роблять речі виключно з марноти (або завдяки OCD) і нічого іншого. Мої труси справді закручуються з тими людьми.

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

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

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

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

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

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

Але також, це залежить від того, що ви маєте на увазі під «чистим кодом».

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

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

int foo    = 1;
int bar    = 2;
int foobar = 3;

легше читати, ніж

int foo = 1;
int bar = 2;
int foobar = 3;

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

Крім того, в PHP вам дозволяється будь-яка кількість блоків випадкових кодів. Я використовую їх для групування логічних завдань:

// do x
{
    // ...
}

// do y
{
    // ...
}

Це додає чітке визначення до відповідного коду.

Редагувати : Як додатковий бонус, легко перейти до одного з цих блоків логічного коду, if (false)якщо ви хочете тимчасово пропустити його.

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