Чи простота завжди покращує читабельність?

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

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

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

Однак я поставив під сумнів припущення, що стоїть за цим натиском:

Чи простота завжди покращує читабельність?

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

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

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

Я буду використовувати в якості прикладу деякий код Haskell, про який я писав деякий час тому. Я задав запитання про stackoverflow про використання монади List для обчислення лічильника, в якому кожна цифра може мати іншу базу. Моє можливе рішення (не знаючи багато Хаскеля) виглядало так:

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Одна з відповідей зводила це до:

count = mapM (enumFromTo 0)

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

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

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

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

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

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

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

Завжди? - НІ

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

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

Якщо я намагаюся простоти, я можу написати такий код:

10000000000000000000000000000000000000000000

Але якщо я піду для читабельності, я віддаю перевагу такому:

1e43

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

Це вироджений приклад набагато більш загальної моделі, яку ви можете знайти майже де завгодно - побудова чогось із дуже простих блоків може швидко стати нечитабельним / неефективним / поганим у багатьох різних способах. Узагальнення та повторне використання, з іншого боку, спочатку важче ("wtf це e?! Це вони мали на увазі писати 1343?", Хтось може сказати), але може допомогти багато в чому.

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

Чіткість + Стандарти + Повторне використання коду + Хороші коментарі + Хороший дизайн може покращити читабельність .

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

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

Чи простота завжди покращує читабельність?

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

Існує компроміс між меншим кодом і більш простим кодом.

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

"Зробіть речі максимально простими, але не простішими", - часто переказуючи Альберт Ейнштейн

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

Чи простота завжди покращує читабельність? Так. Чи одне твердження на рядок завжди простіше? Ні. У кількох мовах є потрійний оператор, який, зрозумівши, простіший і легший для розуміння, ніж еквівалентний присвоєння if / else.

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

Інший приклад: регулярні вирази роблять багато, як правило, лише в одному рядку, а еквівалент без регулярного вираження часто читати набагато складніше. / \ d {3} [-] \ d {3} - \ d {4} / є еквівалентом виклику функції, щонайменше, декількома коментарями, і його легше зрозуміти, ніж відповідний орган функції.

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

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

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

Отже, добре вибране довше ім'я змінної може ...

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

Так само я можу написати if (some_boolean == true). У порівнянні з рівноцінною альтернативою if (some_boolean), цей ...

• Знижує стислість
• Зменшує синтаксичну простоту, але
• Може покращити читабельність шляхом кращого вираження намірів.

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

Що, безумовно, є ще одним свідченням загальної суб'єктивності.

Ви всі пропускаєте деякі фундаментальні визначення . Простий, з кореневого sim-plex , означає одну складку . Просте означає робити одне . Легко, з кореневої легкості , означає лежати поруч . Легко означає, що він знаходиться поруч . Приклади простого коду, наведені в інших відповідях, не є саме такими, якими вони з’являються.

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

10000000000000000000000000000000000000000000

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

1e43

Не могли б ви описати "простий" фрагмент коду Айдана як одну справу? Він містить 10 рядків коду (не рахуючи коментарів) і щонайменше 7 блоків (як я їх порахував). Якщо ви слідкуєте за коментарями, ви побачите, що це робить принаймні 4 речі!

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

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

count = mapM (enumFromTo 0)

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

Чи простота завжди покращує читабельність?

Я б сказав, може, з невеликою суперечкою, зовсім ні .

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

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

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

Простота

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

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

Лісп

І все ж у мене була коротка пристрасть до LISP приблизно в середині 90-х (пізніше). Це змінило всю мою думку про «простоту».

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

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

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

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

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

Мінімалізм

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

Безпека

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

Чисті функції та незмінні стани стали для мене кращими, коли б я міг собі це дозволити, навіть якщо синтаксис:

sword = sharpen(sword)

... трохи менш відвертий і відсторонений від людського мислення, ніж:

sharpen(sword)

Читання VS. Простота

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

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

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

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

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

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

Завжди? - ТАК

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

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

Гарна абстракція варта того, що вона важить в золоті. Хороша абстракція робить це простішим - і, отже, більш читабельним.

Питання нагадують мені цю відповідь на Stack Overflow, зокрема цю цитату (замінити якість простотою):

Якість - ви знаєте, що це таке, але ви не знаєте, що це таке. Але це суперечливо. Але деякі речі кращі за інші, тобто вони мають більшу якість. Але коли ви намагаєтесь сказати, що таке якість, крім речей, які в ній є, це все набуває глузду! Нема про що говорити. Але якщо ви не можете сказати, що таке якість, то як ви знаєте, що це таке, або як ви знаєте, що воно навіть існує? Якщо ніхто не знає, що це таке, то для всіх практичних цілей його взагалі не існує. Але для всіх практичних цілей воно дійсно існує. На чому ще базуються оцінки? Чому б інакше люди платили статки за одні речі і кидали інших у купу сміття? Очевидно, що деякі речі є кращими за інші - але в чому полягає `` кратність ''? - Тож кругом і кругом ви йдете, крутяться ментальні колеса і ніде не знайти місця, де дістати тягу. Яка біса якість? Що це?

Я вважаю, що важливо пам’ятати, що кодифікований стандарт кодування для всіх його переваг не дозволить хорошим програмістам вийти з поганих. Слово на кшталт "просте" у різних людей може трактуватися по-різному (див. Відповідь Айдана Каллі), але це може бути не так вже й погано. Молодші програмісти все ще потребують перегляду свого коду старшими програмістами та дізнаються, чому інтерпретація «простих» старших програмістів краще, ніж їхня власна.

Один виклик функції на лінію простіше? Спробуємо приклад!

=== One call per line ===
x = y.getThis()
a = x.getThat()
b = a.getSomethingElse()

=== Less "simple" version ===
b = y.getThis().getThat().getSomethingElse()

Як ти гадаєш? Чи один дзвінок на лінію насправді простіший?