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

32

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

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

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

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

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

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

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

Ричард
источник
16
Если альтернативой является «умный» код, тогда да ...
Одед
2
да - согласно бритве Оккама - en.wikipedia.org/wiki/Occam%27s_razor
aggietech
17
Старайтесь избегать использования таких жестких терминов, как всегда и никогда. Это сделано для того, чтобы избежать сосредоточения внимания на крайних случаях и вместо этого сосредоточиться на наиболее распространенных проблемах, с которыми мы сталкиваемся. Вот что такое лучшие практики.
P.Brian.Mackey
на самом деле, вы хотите 2 функции / операции на строку. a = bэто одна операция, b + cэто вторая, что означает a = b + c2 операции. Цепочка 2 функций / операторов по-прежнему читаема:, foo(bar())или a = foo().
zzzzBov
2
Кроме того, не волнуйтесь слишком сильно. Если вы попытаетесь исключить каждую часть субъективности из своих объяснений, точно так же, как если бы вы попытались указать каждую возможную деталь стиля кодирования в миллион или более правил, ваши стандарты будут слишком сложными, нечитаемыми, игнорируемыми и, следовательно, бессмысленными.
Steve314

Ответы:

47

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

Я буду использовать в качестве примера некоторый код на 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)

То, что из них «проще» понять (т. Е. Более читабельно), полностью зависит от того, насколько удобно читателю выполнять (абстрактные) монадические операции (и, в этом отношении, бессмысленный код). Читатель, который очень доволен этими абстрактными понятиями, предпочтет прочитать (короткую) более абстрактную версию, в то время как тот, кто не знаком с этими операциями, предпочтет прочитать (длинную) более конкретную версию. Не существует единого ответа о том, какая версия более читабельна и подходит для всех.

Эйдан Калли
источник
11
Некоторые разработчики будут прогрессировать, пока не поймут и не предпочтут однострочник. Трудно представить разработчика, который понимает, что однострочник предпочитает длинную версию. Поэтому ИМО однострочник явно лучше.
Кевин Клайн
7
@kevincline - если разработчик работает изолированно, я согласен, более короткая версия (вероятно) лучше. Если она работает как часть команды, и команда находится не на том уровне, на котором они понимают и предпочитают однострочную версию, и все они должны быть в состоянии поддерживать код, тогда длинная версия (вероятно) лучше в этих обстоятельствах ,
Эйдан Калли
6
В качестве контрапункта: учитывая, что вы опытный Хаскеллер, вы можете сразу же прочитать вторую версию. Первая версия, с другой стороны, потребует чтения и понимания значительно большего количества кода; Вы не могли бы сделать это одним взглядом. Я думаю, что это делает второй вариант проще.
Тихон Джелвис
6
@ Steve314: mapMдовольно идиоматично, и enumFromToделает именно то, что говорит на жестяной банке. В общем, я считаю, что на самом деле проще делать ошибки по одному, если вы расширяете код - в нем просто больше кода, в котором можно ошибиться. Это особенно заметно в таких вещах, как циклы for и процедуры более высокого порядка в других языках. , но я считаю, что это общий принцип.
Тихон Джелвис
1
@ Тихон - но это не обязательно означает чтение такого большого количества кода, и код прямо здесь. Это означает, что могут быть компромиссы. Обычно сильно односторонние в пользу использования существующих функций, а не переизобретения колеса, но есть исключения. Это становится очень очевидным в C ++ с некоторыми более тривиальными «алгоритмами» в стандартной библиотеке - иногда их использование может быть более многословным и менее понятным, чем непосредственное написание кода.
Steve314
13

Если ваш стандарт кодирования касается «удобочитаемости, ремонтопригодности, надежности и производительности», просто укажите это .

Не пытайтесь предписывать, как этого добиться, так как всегда будут ситуации, когда есть контрпример.

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

Мартин Йорк
источник
Это была цель, к которой я стремился, и это было заявленной целью. Простота (точнее, одна функция / операция на строку), естественно, вытекает из этой цели. Я пытаюсь выяснить, было ли мое понимание неверным. Когда вы создаете стандарты кодирования, создание набора правил и руководств - вот и весь смысл упражнения. Установление слишком расплывчатых правил и рекомендаций бесполезно. Таким образом, этот ответ действительно не помогает.
Ричард
5
Мой аргумент заключается в том, что слишком строгие правила являются хуже, чем бесполезны, и на самом деле вредны. Установка правил, таких как одно утверждение в строке, является стилистической. Это то, что определенно НЕ должно быть в руководстве по коду. Это не дает реальной выгоды и может нанести вред удобочитаемости и удобству обслуживания, если применять его бездумно.
Мартин Йорк
3
+1 (потому что я не могу +10) Распространенная ошибка, которую я вижу с новыми менеджерами по программированию, состоит в том, что они пытаются кодифицировать каждую мельчайшую деталь. Лучшие стандарты кодирования больше похожи на печенье с предсказанием, чем на рецепты.
JohnFx
«Стили и стандарты кодирования» - это название документа. Очевидно, что это не стандарт (как в «Никогда не используйте GoTo» или «Никогда не используйте короткие целые»), а стиль. Объединяющий стиль важен для удобочитаемости и удобства обслуживания.
Ричард
1
Руководство по стилю: «В этом проекте используются табуляции / пробелы (выберите один). В этом проекте используется стиль скобок K & R / Allman / BSD / GNU (выберите один). Пожалуйста, не добавляйте пустые пробелы в конце строк. код аккуратный и читабельный. Все будет проверено кодом двумя членами команды и вами: для удобства чтения / сопровождения вам потребуется большинство 2/3 для проверки кода, для надежности и производительности вам нужно 3/3 (Пожалуйста, предоставьте соответствующие тесты для подтверждения ). Если правила будут нарушены, будут добавлены дополнительные правила :-) "Готово.
Мартин Йорк
7

Меньше «материала на строку», простота и удобочитаемость - это не одно и то же. Можно взять невероятно сложный непонятный недокументированный алгоритм и кодировать его с 1 оператором на строку вместо 2, и он не станет намного более читабельным.

Меньше «материала на строку» также может потребовать предоставления разработчикам больших мониторов большого размера, чтобы блоки кода теперь располагались более вертикально. Или вызвать усталость глаз от чтения более мелких шрифтов.

Читаемость - это очень собственная метрика, которая часто требует компромисса между несколькими другими, более легко измеряемыми метриками. Предварительно ограничьте все эти другие метрики, и компромисс больше не станет возможным, что приведет к менее читаемому коду.

hotpaw2
источник
5

Всегда? - НЕТ

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

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

DKnight
источник
5

Если я пойду для простоты, я могу написать код так:

10000000000000000000000000000000000000000000

Но если я пойду на удобочитаемость, я предпочитаю это:

1e43

С другой стороны, 1000это намного более читабельно и просто, чем 1e3если вы не работаете с числами в научной записи все время.

Это вырожденный пример гораздо более общего паттерна, который вы можете найти практически где угодно - построение чего-либо из очень простых блоков может быстро стать нечитаемым / неэффективным / плохим разными способами. Обобщая и повторное использование, с другой стороны, труднее в первый ( «WTF это e?! Они имели в виду , чтобы писать 1343?» Кто - то может сказать), но может очень помочь в долгосрочной перспективе.

Rotsor
источник
Ваша точка зрения о том, что «1e3» менее читабельна, чем «100», хорошо сформулирована. Фактически, это отличный пример того, как когнитивная нагрузка влияет на читабельность. «1e3» требует чтения 3 символов и перевода возведения в степень. Чтение «100» требует чтения 3 символов и не требует дальнейшей оценки.
Стивен Гросс
Стивен, на самом деле при чтении трехзначного числа, такого как 100вы, нужно выполнить два умножения и два сложения ( 0+10*(0+10*1)). Однако, привыкнув к этой записи, вы даже этого не замечаете. Это еще раз показывает, насколько субъективным может быть понятие простоты.
Роцор
Интересный. Итак, строго говоря, «100» требует 2 умножения (1 * 100, 0 * 10) и 2 операции сложения. «1e3» требует одну операцию умножения. Таким образом, в отсутствие какого-либо когнитивного контекста , «100» труднее читать, чем «1e3». Но! Если включить когнитивную нагрузку с переключением контекста, расчет будет другим. Поскольку мы обычно читаем целые числа в ненаучной форме, «100» проще. Но если мы пишем инженерное приложение, в котором все числа выражены в научных обозначениях, форма «1e3» будет проще!
Стивен Гросс
2

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

Мейсон Уилер
источник
Сложность не является неснижаемой. У нас есть «абстракция», «чанкинг» и «организация», чтобы попытаться управлять сложностью. Я думаю, что сложная операция может быть описана в несколько простых шагов. Он работает для многих реальных физических процессов: резюме, обзоры и т. Д.
S.Lott
1
@ S.Lott: Да, но достаточная прокрутка и нажатие Ctrl могут усложнить процесс «упрощения». Я видел, как это происходит один или два раза (это не часто, но может быть очень неприятно работать, когда он заходит слишком далеко).
FrustratedWithFormsDesigner
3
@ S.Lott - все еще есть границы того, насколько сложность может быть уменьшена. Вы можете устранить ненужную сложность, но вы можете управлять только (не устранять) необходимой сложностью - сложностью, которая присуща требованиям. Можно предположить, что механизмы управления сложностью также увеличивают сложность - некоторая дополнительная сложность связана с устранением несоответствующей сложности с целью лучшего раскрытия соответствующих деталей для конкретного аспекта / проблемы / конструкции.
Steve314
1
@ S.Lott - Да, конечно, вы можете представить любое требование с помощью исходного файла нулевой сложности (полностью пустой). Но поскольку для выполнения ваших требований вам нужен очень специфический язык, все, что вы делаете, - это переводите свои требования в спецификацию языка.
Steve314
1
@ S.Lott - если вы утверждаете, что можете предсказать положение Юпитера в Рождество, не используя ничего, но G=0я думаю, что вы безумны. Если нет, вы упускаете мою точку зрения. Конечно, вы можете абстрагироваться от ненужных деталей, но это не имеет значения, если ваши требования говорят, что они актуальны. Если вы читаете в ответ, я никогда не утверждал, что вся сложность необходима - только то, что некоторая сложность присуща требованиям и не может быть устранена.
Steve314
2

Ясность + Стандарты + Повторное использование кода + Хорошие комментарии + Хороший дизайн может улучшить читаемость .

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

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

Без шансов
источник
2

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

Нет. Я видел много случаев, когда выполнение нескольких простых вещей в одной строке менее сложно, чем использование нескольких строк.

Существует компромисс между меньшим количеством кода и более простым кодом.

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

Том Сквайрс
источник
1

«Сделайте вещи максимально простыми, но не проще», - часто перефразирует Альберт Эйнштейн.

Простота улучшает все . Для разных значений простоты, конечно. Это меньше строк кода? Может быть. Это меньший исполняемый файл? Возможно. Это то, что ваша команда должна согласовать? Абсолютно .

Джесси С. Слайсер
источник
+1 за цитату, но простота улучшает читабельность?
Ричард
«Сделайте вещи максимально простыми, а затем упростите их» - это лучший вариант, так как инженеры ПО склонны к чрезмерному проектированию.
Mattnz
1
Я бы хотел, чтобы люди перестали говорить: «Делай вещи как можно проще, но не проще». Разве мы не можем, по крайней мере, обобщить MakeAsGoodAsPossibleButNoMoreSo <Thing, Attribute> как наш переход к бесполезно общему инженерному совету? (Извините @Jesse C. Slicer, вы далеко не единственный, кто цитирует это, так что вы не заслуживаете мини-разглагольствования больше, чем кто-либо другой).
PSR
1

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

В языках, которые позволяют задавать несколько переменных в одной строке, это часто проще и проще для понимания, чем любой эквивалент.

Другой пример: регулярные выражения делают много, обычно в одной строке, а эквивалент без регулярных выражений часто намного сложнее для чтения. / \ d {3} [-] \ d {3} - \ d {4} / является эквивалентом вызова функции с минимум несколькими комментариями и легче для понимания, чем соответствующее тело функции.

jmoreno
источник
1

Читаемость и простота - это субъективные термины, которые, в зависимости от человека и контекста, обычно, но не всегда, идут вместе.

Более объективный термин - краткость - то, что в принципе вы можете посчитать, посчитав символы, хотя в этом есть некоторые недостатки. Краткость, кажется, подразумевает простоту и удобочитаемость, но есть (по крайней мере, на мой взгляд) исключения.

Более длинный (и, возможно, более сложный) фрагмент кода может быть более читабельным, если он лучше выражает намерение. Является ли ваше определение простоты заботой о намерении, это еще одна субъективная вещь - вы можете определить сложность с точки зрения синтаксической структуры и энтропии теории информации, например, без ссылки на намерения вообще.

Итак, правильно выбранное более длинное имя переменной может ...

  • Улучшение читабельности за счет лучшего выражения намерений
  • Уменьшить краткость - это дольше, в конце концов
  • Не влияет на синтаксическую простоту вообще - синтаксическая структура кода не изменяется

Точно так же я мог бы написать if (some_boolean == true). По сравнению с аналогичной альтернативой if (some_boolean), это ...

  • Уменьшает краткость
  • Уменьшает синтаксическую простоту, но
  • Может улучшить читабельность за счет лучшего выражения намерений.

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

Что, конечно, еще одно свидетельство общей субъективности.

Steve314
источник
1

Вы все упускаете некоторые фундаментальные определения . Простое, от корневого 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)

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

Энтони Мастреан
источник
1

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

Я бы сказал, может быть, с небольшим количеством противоречий, абсолютно нет .

Вы можете передать мне класс с 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.


источник
0

Всегда? - ДА

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

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

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

С. Лотт
источник
Я не могу не думать, что ваши пугающие цитаты есть, потому что вы знаете, что «концепция» и «кусок» сами по себе субъективны. Одно понятие единственного человека - объединение трех разных людей. Трудно иметь абсолютную и объективную меру субъективных вещей.
Steve314
@ Steve314: напугать цитаты? Нет. En.wikipedia.org/wiki/Chunking Все, похоже, похожи в том, что они описывают упрощение посредством чанкинга. (За исключением техники гитары, это кажется другим.) Там есть кавычки, потому что есть много альтернативных терминов для абстракции, разбиения на части, суммирования и т. Д. Если я выберу только один объект каждый, то абстракция - это не то же самое, что чанкинг. Кавычки здесь , чтобы подчеркнуть , что это как - то спорно. Еще. Это явно делается постоянно и кажется естественной человеческой тенденцией.
С.Лотт
Что я не отрицаю - чанкинг делается постоянно и это хорошая идея. Что я отрицаю - это то, что существует определенное объективное правило для того, где должны быть границы между кусками. Мои аргументы могут быть скорее педантичными, чем полезными, но я все еще сомневаюсь, что «всегда» в «всегда улучшает читабельность».
Steve314
@ Steve314: Мы всегда абстрагируем, разбиваем на части и суммируем, чтобы помочь себе понять вещи. Всегда. Чанкинг, абстрагирование, обобщение («упрощение») - это то, что мы всегда делаем. Мы просто делаем. Так наш мозг воспринимает реальность. Упрощение всегда улучшает читабельность и всегда может быть сделано.
С.Лотт
Да. Я никогда не говорил иначе.
Steve314
-2

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

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

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

KaptajnKold
источник
1
Вот почему я определил простоту в этом вопросе.
Ричард
-2

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

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

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

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

Стивен Гросс
источник
Да. Один звонок на линию проще и удобнее для меня. Тем не менее, читаемость является субъективной. (Кроме того, это даже близко не подходит к ответу на вопрос.)
Ричард
Привет, Стивен, не могли бы вы рассказать, как, по вашему мнению, это отвечает на вопрос? Непонятно, что ты здесь пытаешься указать.
@MarkTrapp Нет проблем. Первоначальный вопрос предлагал подход с одной функцией на строку. В примере, который я разместил, показаны те же два фрагмента кода, один из которых реализован как функция «одна функция на строку», а другой - как вызовы метода chained. Я думаю, что цепочечный вызов намного проще для чтения: короткий, лишенный ненужных временных переменных и элегантный.
Стивен Гросс
Если вам приходится цеплять геттеры, то ваш код предназначен для пула
зима