Чи варто жертвувати читабельністю коду тим, наскільки ефективний код? [зачинено]

Чи варто жертвувати читабельністю коду тим, наскільки ефективний код?

наприклад, 3 рядки коду в 1 рядок.

Я читав у Code Craft Піта Гудліффа, що читабельність є ключовою.

Ваші думки?

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

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

-Абелсон і Суссман, структура та інтерпретація комп'ютерних програм

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

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

Іноді так.

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

Для прикладу останнього дивіться статтю " Швидкий зворотний квадрат" у Вікіпедії.

Я, як правило, вважаю, що краще зробити щось читабельне спочатку і хвилюватися про продуктивність після того, як будуть вжиті заходи щодо здорового глузду, такі як не вибір алгоритму O (n ^ 2) над O (n). На мою думку, жертва читанні лише заради стислості є помилковою.

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

Це не говорить про те, що перезапис повинен бути, звичайно, нечитабельним.

Я цитував це раніше , і я його цитую ще раз:

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

У тому порядку.

Уес Дайер

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

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

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

На мій погляд, абсолютно немає приводу не мати декількох основних коментарів. Очевидно if ( x == 0 ) /* check if x is 0 */, абсолютно марно; не слід додавати зайвий шум у код, але щось подібне:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

Це дуже корисно.

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

Якщо ефективність - ваша поточна мета (як, наприклад, на етапі оптимізації), і ви знаєте - у вас є показники, чи не так? - що рядки коду є поточним вузьким місцем, тоді так.

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

Ніхто не виграє Code Golf

наприклад, 3 рядки коду в 1 рядок

Особливо страшна ідея.

Вартість гри в код-гольф - дуже висока.

Вартість на підтримку нечитабельних програм - астрономічні.

Значення цього виду мінімізованого коду - нуль. Він все ще працює, але не працює «краще».

Мудро вибрана ефективність

Вартість на вибір правильного алгоритму та структури даних - помірна.

Вартість підтримки правильного алгоритму та структури даних - низька.

Значення правильного алгоритму та структури даних - високе. Використання ресурсів низьке.

Дурне ("мікрооптимізація") Ефективність

Вартість на мікрооптимізацію - висока.

Вартість підтримки нечитабельного мікрооптимізованого коду - дуже висока.

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

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

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

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

Я не приймаю аргумент "читабельність над ефективністю". Дозвольте дати вам відповідь з іншим спіном.

Деякі передумови: Ви знаєте, що мене нудить? Коли я двічі клацну на "Моєму комп'ютері", і мені доводиться чекати, поки він заповниться. Якщо це займе більше 5 секунд, я дуже засмучуюся. Дурне, і не просто звинувачуйте Microsoft у цьому, це те, що в деяких випадках причина цього займає так довго, що потрібно приймати рішення про те, який значок показувати! Це вірно. Тож ось я сиджу, цікаво лише зайти до свого C: диска, і мені доведеться чекати, коли драйвер отримає доступ до мого компакт-диска та прочитає піктограму звідти (якщо припустити, що в диску є компакт-диск).

ДОБРЕ. Тож на секунду уявіть всі шари між мною, двічі клацнувши на Мій комп'ютер, і він насправді розмовляє через драйвери на компакт-диску. А тепер уявіть, що кожен шар був ... швидшим ...

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

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

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

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

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

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

Хороший приклад - ім’я змінної: $a

Що таке $a?? Це поза контекстом, тому ви не можете на це відповісти, але чи стикалися ви з цим у фактичному коді? Тепер припустимо, що хтось написав $file_handle- тепер що це? Це зрозуміло навіть поза контекстом. Довжина імені змінної робить незначну різницю для комп'ютера.

Я думаю, що тут є здоровий глузд.

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

* це залежить від промисловості та інших подібних речей. Я дивлюся на це з точки зору розробника бізнес-програмного забезпечення (Business Information Systems).

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

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

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

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

x++; // Add one to x

Швидше прокоментуйте вас, читачу, через 6 місяців або 12 місяців або якийсь інший досить тривалий час. Прийняти стандарт кодування та дотримуватися його.

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

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

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

Читання - це привід для некомпетентних та ледачих програмістів (насправді те саме стосується "простоти", коли використовується як аргумент для захисту хитрого алгоритму / дизайну)!

Для кожної заданої проблеми слід прагнути до оптимального рішення! Те, що комп’ютери сьогодні швидкі, не є приводом для того, щоб витрачати цикли процесора. Єдиним обмеженням має бути "час доставки". Зауважте, що "оптимальне рішення" означає те, що ви можете придумати (ми не всі можемо придумати найкраще рішення; або маємо навички / знання для їх реалізації).

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

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

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