Як ви можете пояснити "прекрасний код" непрограмісту? [зачинено]

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

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

Мовна аналогія

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

Будівельна аналогія

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

На противагу тому, що в будинку, де все там, де має бути, він є низьким рівнем обслуговування, ідеально утеплений, так що трохи сонячного тепла буде зберігати тепло взимку, енергія відбирається від вентиляції, тому у вас є і свіже повітря, і комфортна температура і мізерні рахунки за електроенергію. Він побудований з негорючих матеріалів, щоб не міг згоріти від пожежі. Він витримає землетрус 9,0 та торнадо F5. Побудувати це коштує лише на 30% більше, ніж інший будинок, але різниця окупиться через 5 років. І це естетично.

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

Подумайте про машину.

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

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

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

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

Я б посилався на поезію:

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

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

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

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

Для мене Quicksort є прекрасним прикладом: виберіть випадковий елемент з масиву, а потім порівняйте з ним кожен інший елемент масиву; якщо кількість менше, ніж його, покладіть у купу A; якщо число більше, ніж його, покладіть його в купу B. Тепер, за нерівності трикутника, жоден елемент у купі A ніколи не буде потрібно порівнювати з будь-яким елементом у купі B. Повторіть на A і B, і ви закінчите .

Нагадує про це:

Джерело: XKCD - LISP

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

• Читабельність
• Лаконічність
• Ефективність
• Гнучкість
• Явність
• Міцність
• Безпека / безглуздість
• Повнота
• Послідовність
• Простота використання (для API)

Картини Джексона Поллока є прикладом чогось прекрасного для одних і химерного для інших.

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

Деякі аспекти хорошого коду:

1. У ньому велика кількість дрібних деталей, які всі вказують в одному напрямку
2. вона послідовна за своєю структурою , кожна частина слідує тій же схемі
3. але це не повторюється , натомість кожна частина є різною
4. він також не дозволяє поведінку, яка вважається недійсною
5. він має найменшу можливу кількість різних станів
6. ви можете зрозуміти всю поведінку коду , прочитавши прототипи функцій
7. він не має побічних ефектів
8. виконання його гарантовано припиняється
9. він не використовує жодних розширених функцій, доступних у мовах програмування
10. вона не надто складна порівняно зі складністю проблеми, яку вона вирішує
11. в ньому немає помилок або невизначеної поведінки
12. його можна скласти компіляторами від декількох різних постачальників
13. він не має залежності від коду, який не використовується

Для мене мова (мови) - це мої інструменти.

І як і будь-який майстер, я вважаю за краще, щоб мої інструменти були в м'ятному стані.

Чим кращий стан коду щодо чіткості концепції, ремонтопридатності та читабельності. тим краще код.

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

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

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

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

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

На мою скромну та особисту думку, гарний код - це як хороша книжка-роман:

• ви можете прочитати його від початку до кінця / вам не потрібно буде пропускати вперед на майбутні сторінки книги, щоб зрозуміти поточну сторінку.
• у неї немає зайвих повторів / книга є дещо нудною, якщо вона завжди говорить одне і те ж.
• намір кожної частини очевидний майже кожен раз / вам не потрібно мати словник біля себе, щоб читати книгу (якщо тільки це поезія / код для гольфу xD).
• він організований у підструктури доступних розмірів та складності (модулі, функції, заяви тощо), він не має надто «вкладеності» / глав, абзаців та пропозицій, правильно збалансованих; вона не використовує занадто багато рівнів підрядного речення тощо.
• це приємно для ока в естетичному вигляді (красиво відрізане, блоки правильно розмежовані тощо) / як книга з належним набором тексту.

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

Vs.

Офісний простір, де підтримується посередність, троє менеджерів не мають нічого кращого, ніж помилятися з повідомленнями про TPS,! @ # $ Ing FAX MACHINE Ніколи не працює! і будь-який працівник може отримати лише близько 15 хвилин фактично виконаної роботи на тиждень. Співробітник, можливо, навіть технічно не працює там більше, тому що хтось забув його звільнити (важко сказати, бо ніхто не працює ефективно, і важко оцінити, що вони намагаються досягти). А для того, щоб зробити що-небудь практичне, потрібно переходити до абсурдно надто складної системи, про яку хтось читав і думав, буде виглядати акуратно на їх резюме, хоча це насправді не вирішує проблему, яку вони мали.

Немає "красивого коду", є "елегантні алгоритми" та "елегантні конструкції". Дизайн можна зрозуміти непрограмістам.

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

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