Всегда ли простота улучшает читабельность?

Недавно я разрабатывал набор стандартов кодирования для нашей компании. (Мы новая команда, разрабатывающая новый язык для компании.)

В своем первом проекте я поставил цель наших стандартов кодирования: улучшить удобочитаемость, ремонтопригодность, надежность и производительность. (Я проигнорировал возможность записи, переносимость, стоимость, совместимость с предыдущими стандартами и т. Д.)

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

Однако я поставил под сомнение предположение этого толчка:

Всегда ли простота улучшает читабельность?

Есть ли случай, когда написание более простого кода снижает читабельность?

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

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

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

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 , означает один раз . Простое означает делать одну вещь . Легко, от корня легкость , значит лежать рядом . Легко означает, что это под рукой . Примеры простого кода, приведенные в других ответах, не совсем то, что они появляются.

Возьмите дисплей Роцора с очень большим значением. Он говорит, что это просто . На мой взгляд, не все так просто. Это просто. Это под рукой, чтобы набрать количество обязательных 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 является примером того, что я считаю «чрезвычайно простым». Это "слишком просто и слишком нечитаемо" на мой личный вкус. Для меня существует баланс между этими крайностями, но у regex действительно есть такое простое LISP-качество, как я его определяю: минимализм, симметрия, невероятная гибкость, надежность и т. Д. Проблема для меня в том, что это настолько просто, что это стало настолько нечитаемым до такой степени, что я не думаю, что когда-либо стану свободно владеть этим (мой мозг просто так не работает, и я завидую людям, которые могут свободно писать код регулярных выражений).

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

Всегда? - ДА

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

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

Хорошая абстракция на вес золота. Хорошая абстракция делает это проще - и, следовательно, более читабельным.

Вопросы напоминают мне об этом ответе о переполнении стека, особенно об этой цитате (замените качество простотой):

Качество - вы знаете, что это такое, но вы не знаете, что это такое. Но это противоречиво. Но некоторые вещи лучше других, то есть у них больше качества. Но когда ты пытаешься сказать, что это за качество, кроме того, что имеет его, все это теряет смысл! Тут не о чем говорить. Но если вы не можете сказать, что такое Качество, как вы узнаете, что это такое, или откуда вы знаете, что оно вообще существует? Если никто не знает, что это такое, то для всех практических целей его вообще не существует. Но для всех практических целей это действительно существует. На чем еще основаны оценки? Почему еще люди платят целое состояние за одни вещи, а другие бросают в кучу мусора? Очевидно, что некоторые вещи лучше, чем другие, но что за «лучшее»? - Так иди вокруг, иди, закручивая ментальные колеса и нигде не найдя где-нибудь тяги. Какого черта это качество? Что это такое?

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

Один вызов функции на строку проще? Давайте попробуем пример!

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

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

Что вы думаете? Действительно ли один вызов на линию проще?