Що означає написати "хороший код"? [зачинено]

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

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

То що означає писати "хороший код"? Що таке "хороший код"?

Хороший кодер - це як хороший гравець у більярд.

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

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

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

( оригінал )

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

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

"WTF's per minute" (вище) є правдою, але це лише наслідки більш загального правила. Чим більше WTF, тим повільніше розуміння.

Ви знаєте, що ви пишете хороший код, коли ...

1. Замовник задоволений
2. Колеги-співробітники запозичують ваш код як вихідний пункт
3. Зовсім новий хлопець / гал щойно сказав, щоб внести зміни в систему, яку ви побудували 6 місяців тому, і він / вона жодного разу не задавав вам питання
4. Ваш начальник просить розробити нові віджети для команди, якими користуватиметесь
5. Ви дивитесь на код, який ви пишете сьогодні, і кажете собі "Я б хотів, щоб я написав такий код два роки тому"

Як ви вимірюєте, чи добре код ...

• Який час відповіді?
• Скільки туди і назад на сервер?
• Ви особисто використовуєте додаток чи вважаєте, що це незграбно?
• Чи побудували б ви його наступним чином?

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

Код, який є

1. помилка безкоштовно

2. багаторазове використання

3. незалежний

4. менш складний

5. добре задокументовані

6. легко переслідувати

називається хорошим кодом.

Хороша програма працює бездоганно і не має помилок. Але які внутрішні якості виробляють таку досконалість ?. Це не таємниця, нам просто потрібні деякі випадкові нагадування. Незалежно від того, чи кодуєте ви в C / C ++, C #, Java, Basic, Perl, COBOL або ASM, все хороше програмування має однакові якості: простота, читабельність, модульність, шаруватість, дизайн, ефективність, витонченість та чіткість, ефективність, елегантність та ясність

Джерело: MSDN

Це здається вам знайомим?

Philips дав мені можливість спостерігати за дизайном нового продукту. У міру розвитку я ставав все більш непростим і почав довіряти свої занепокоєння своєму керівнику. Я неодноразово говорив йому, що конструкції не є "чистими" і що вони повинні бути "красивими" так, як дизайни Діккстри були красивими. Він не вважав це корисним коментарем. Він нагадав мені, що ми були інженерами, а не художниками. У його думці я просто висловлював свій смак, і він хотів знати, яким критерієм я користуюся при прийнятті свого судження. Я не зміг йому сказати! Оскільки я не міг пояснити, які принципи порушуються, мої коментарі просто ігнорувались і робота тривала. Відчуваючи, що повинен бути спосіб пояснити і надати мотивацію моєму «смаку», Я почав намагатися знайти принцип, який би відрізняв гарні конструкції від поганих. Інженери дуже прагматичні; вони можуть захоплюватися красою, але шукають корисності. Я намагався знайти пояснення, чому «краса» була корисною.

Будь ласка, дивіться решту тут .

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

int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);
++i;

на відміну від

Record r = cache.get(i++, false);

Можливо, допоможе відповідь, проілюструвавши протилежне (плюс це привід сюди потрапити XKCD ).

Хороший код

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

Приклади включають

• Apache Commons
• Весняні рамки
• Зимова сплячка

Я просто поїду з "ремонтопридатним"

Весь код повинен підтримуватися: не потрібно робити це завдання складніше, ніж необхідно

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

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

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

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

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

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

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

Навіть більше, управління багатьма науковими програмами може мати вирішальне значення. Код, який дуже легко читається, як правило, неохайний у використанні пам'яті: створюється просто більше об'єктів. У багатьох випадках розумне використання пам'яті робить код знову менш читабельним. Але якщо, наприклад, підмітати навколо гігабайт послідовностей ДНК, пам'ять є вирішальним фактором. Знову ж таки, я вважаю, що менш об'ємний об'єм пам'яті є кращим кодом, незалежно від готовності.

Так що так, читальність важлива для хорошого коду. Я знаю адагію Уве Ліґгіса: Думати боляче і комп'ютери - це дешево. Але в моїй галузі (статистична геноміка) обчислювальний час на тиждень та використання пам'яті понад 40 Gb не вважаються ненормальними. Таким чином, покращення вдвічі більше швидкості та половини пам’яті коштує набагато більше, ніж цей додатковий біт читальності.

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

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

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

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

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