Стоит ли жертвовать читабельностью кода тем, насколько он эффективен? [закрыто]

37

Стоит ли жертвовать читабельностью кода тем, насколько он эффективен?

например, 3 строки кода в 1 строку.

Я прочитал в Code Craft Питом Гудлиффом, что читабельность - это ключ.

Твои мысли?

TeaDrinkingGeek
источник
13
Как вы думаете, почему код с меньшим количеством строк, вероятно, более эффективен? Это редко случается с современными языками, хотя это может относиться к 8-битным интерпретаторам языка BASIC
Дэвид Торнли
69
Ни читаемость, ни производительность не измеряются в строках.
В очень немногих случаях я жертвовал бы удобочитаемостью ради скорости, но очень редко. Встроенный код, работающий на высокоскоростном оборудовании, - один из примеров. Для большинства программ удобочитаемость гораздо важнее.
Джим С
1
Соответствующий ответ: programmers.stackexchange.com/questions/39047/…
Николь,
Я бы всегда отдавал предпочтение удобочитаемости, пока производительность не станет проблемой. Тогда я бы начал беспокоиться об этом.
Пит

Ответы:

62

«Меньше линий» не всегда то же самое, что «более эффективный». Я предполагаю, что вы имеете в виду «Должна ли программа быть короче за счет читабельности».

Программы должны быть написаны для того, чтобы люди могли читать, и только для машин.

-Abelson & Sussman, структура и интерпретация компьютерных программ

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

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

оборота Инамати
источник
3
+1 Возврат уменьшается, но я также обнаружил, что короткую программу обычно легче читать, чем длинную.
Майкл К
23
К сожалению, я обнаружил, что одноразовый код для удаления данных, который не удаляется сразу, слишком часто превращается в долгосрочный код. Всегда ожидайте, что все будет зависеть, использоваться повторно и расширяться, если только вы не удалите код.
Vatine
1
Я согласен с Ватином. Ты когда-нибудь возвращаешься и пытаешься выяснить что-то, что ты когда-то считал "совершенно ясным", когда?
Вонко вменяемый
+1 для SICP. Потрясающая книга.
Джейсон Йео
30

Иногда да.

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

Пример последнего см. В статье « Быстрый обратный квадратный корень» в Википедии.

Я вообще думаю, что лучше сначала сделать что-то читаемым, а потом беспокоиться о производительности, при условии, что приняты меры предосторожности, такие как отказ от выбора алгоритма O (n ^ 2) вместо O (n). На мой взгляд, жертвенность удобочитаемостью ради краткости ошибочна.

Адам Лир
источник
4
Я думаю, что может быть разница между «читаемым кодом» и «знанием алгоритма». Я предполагаю, что любой код, если вы не знаете алгоритм, будет более или менее трудным для чтения и понимания. Например, в упомянутом случае FISR простой код на самом деле вполне читабелен, но алгоритм не документирован. Если бы вы знали алгоритм FISR, насколько читабельнее вы могли бы написать код? Тесно связанный вопрос может быть: когда выбрать причудливый алгоритм?
Маглоб
@Maglob Я специально имел в виду использование 0x5f3759df. Безотносительно к производительности вы можете использовать реализацию алгоритма ISR с использованием регулярного деления, которое, вероятно, будет более читабельным для человека, менее знакомого с внутренними компонентами компьютера.
Адам Лир
3
Возможно, это можно выразить так: «Иногда правильно заменить простой алгоритм, выраженный в 5 строках комментариев и 20 строках кода, сложным алгоритмом, выраженным в 15 строках комментариев и 5 строках кода».
Питер Тейлор
1
Имейте также в виду, что то, что ужасно глупое запутывание для разработчика в одном домене, может быть совершенно приемлемой идиомой для разработчика в другом домене. Хотя магическая константа в алгоритме ISR, кажется, немного раздвинула границы, я предполагаю, что в то время такого рода взлом на битовом уровне для приближений с плавающей запятой был довольно распространенным явлением в то время. Точно так же, работая во встраиваемых системах, мы сталкиваемся с множеством проблем, которые идиоматичны, но могут показаться слишком тупыми разработчикам приложений.
Cercerilla
одно из чудес Интернета -> при реализации сложного алгоритма (пример: расстояние Левенштейна с диагональной оптимизацией ... я просто работаю над этим;)), можно либо ссылаться на статью, либо даже копировать статью в документации проекта и вставьте ссылку в код. Таким образом, люди, знающие алгоритмы, просто следуют комментариям, которые объясняют конкретные тесты / оптимизации, в то время как начинающие сначала должны прочитать об алгоритме, а затем вернуться к реализации.
Матье М.
22

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

Это не говорит о том, что переписывание должно быть нечитаемым, конечно.

ChrisF
источник
22

Я цитировал это раньше , и я процитирую это снова:

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

В этой последовательности.

Уэс Дайер

оборота Бенджол
источник
2
+1 Я быстро прокрутил страницу вниз, чтобы убедиться, что эта цитата включена. Теперь мне не нужно вводить ответ. :-)
RationalGeek
9

Стоит ли жертвовать читабельностью кода тем, насколько он эффективен?

С точки зрения кода, всегда приятно самодокументироваться. Но иногда этого не может быть. Иногда вам нужно оптимизировать, а иногда этот код сам по себе не очень читабелен.

Для этого и были придуманы комментарии . Используй их. Даже на сборке есть комментарии. Если вы написали массу кода, а комментариев нет, я беспокоюсь. Комментарии не влияют на производительность во время выполнения, но всегда помогают несколько заметок о том, что происходит.

На мой взгляд, нет абсолютно никаких оправданий, чтобы не иметь несколько основных комментариев. Очевидно, что if ( x == 0 ) /* check if x is 0 */это абсолютно бесполезно; Вы не должны добавлять ненужный шум в код, но что-то вроде этого:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

Это довольно полезно.

user10197
источник
6

Стоит ли жертвовать читабельностью кода тем, насколько он эффективен?

Если эффективность - ваша текущая цель (как на этапе оптимизации), и вы знаете - у вас есть метрики, не так ли? - эта строка (и) кода является текущим узким местом, тогда да.

В противном случае no: удобочитаемость позволит вам (или другому пользователю) позже изменить этот код, чтобы сделать его более эффективным, так как его легче понять.

оборота клаим
источник
4

Никто не выигрывает Code Golf

например, 3 строки кода в 1 строку

Особенно ужасная идея.

Стоимость игры в гольф-код - очень высокая.

Стоимость поддержки нечитаемых программ - астрономическая.

Значение такого вида минимизированного кода - ноль. Это все еще работает, но не работает "лучше".

Мудро-Избранная Эффективность

Стоимость выбора правильного алгоритма и структуры данных - умеренная.

Стоимость поддержания правильного алгоритма и структуры данных - низкая.

Значение правильного алгоритма и структуры данных - высокое. Использование ресурсов невелико.

Глупая («микрооптимизация») эффективность

Стоимость поиграть в микрооптимизацию - высокая.

Стоимость поддержки нечитаемого, микрооптимизированного кода - очень высокая.

Ценность микрооптимизации - варьируется. Когда здесь есть ненулевое значение, затраты все равно перевешивают его.

S.Lott
источник
2

Зависит от того, говорим ли мы об эффективности с точки зрения скорости выполнения кода или эффективности о том, насколько быстро разработчик может написать код. Если вы жертвуете читабельностью кода ради возможности очень быстрого ввода кода, то вы, скорее всего, будете тратить время на отладку.

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

rjzii
источник
2

Я не принимаю аргумент «удобочитаемость за производительность». Позвольте мне дать вам ответ с другим оттенком.

Немного предыстории: Вы знаете, что меня тошнит? Когда я дважды щелкаю на «Мой компьютер», мне приходится ждать, пока он заполнится. Если это займет больше 5 секунд, я очень расстроен. Глупо, и не просто обвинять в этом Microsoft, это то, что в некоторых случаях причина, по которой это занимает так много времени, заключается в том, что необходимо принять решение о том, какую иконку показывать! Это верно. Итак, я сижу, интересуюсь только переходом на мой диск C: и мне нужно подождать, пока драйвер получит доступ к моему CD-ROM и прочтет значок оттуда (при условии, что в приводе есть CD).

ХОРОШО. Так что на секунду представьте, что все слои между мной дважды щелкают по Моему компьютеру, и он фактически общается через драйверы с CD-ROM. Теперь представьте, что каждый слой был ... быстрее ...

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

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

Maltrap
источник
«Хорошо. Итак, на секунду представьте, что все слои между мной дважды щелкают по« Моему компьютеру », и он фактически общается через драйверы с CD-ROM. Теперь представьте, что каждый слой был… быстрее…» для меня сразу с двумя DVD Диски
Rangoric
Одним словом: Обновление
jmort253
2
Ребята, работайте со мной здесь, это иллюстрация ...
Maltrap
@Rangoric это то, что я называю использованием достижений в технологии в качестве опоры, а не подарка. Это хорошо работает в отрасли, если вы можете убедить пользователей чаще открывать свои кошельки.
Джонатан Нойфельд
Я думаю, что энергетическое воздействие раздутого кода требует более тщательного и строгого контроля. Экологическое управление здесь отсутствует. Учитывая, что сейчас мы наблюдаем повышение глобальной температуры на 4 градуса, почему сложность вычислений отодвигается на второй план?
Джонатан Нойфельд
2

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

Некоторое время назад я прочитал довольно хорошую книгу под названием «Разработка на основе доменов: Проектирование на основе доменов: решение сложных задач в основе программного обеспечения». Конечно, вначале это немного сухое чтение, но материал хорошо представлен. Это показывает хороший подход, который приводит к системам, которые хорошо документируют себя. Язык является средой для передачи вашего решения, поэтому, чем яснее решение, тем легче адаптироваться, если производительность становится критическим фактором. Это мое убеждение, и оно, похоже, хорошо сработало для меня.

Desolate Planet
источник
1

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

С этой целью я считаю читабельность очень важной. Конечно, как говорилось много раз, просто потому, что код читабелен, не обязательно означает, что он медленнее.

Хорошим примером является имя переменной: $a

Что такое $a?? Это вне контекста, так что вы не можете ответить на этот вопрос, но сталкивались ли вы с этим в реальном коде? Теперь предположим, что кто-то написал $file_handle- что это? Это понятно даже вне контекста. Длина имени переменной имеет незначительное значение для компьютера.

Я думаю, что здесь есть здравый смысл.

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

* это зависит от отрасли и других подобных вещей. Я смотрю на это с точки зрения разработчика программного обеспечения для бизнеса (Business Information Systems).


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

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

Поэтому на практике я думаю, что вы, скорее всего, навредите себе или другим ... (Я бы предпочел, чтобы мои выходные вернулись.)

Фрэнк V
источник
1

В большинстве случаев ответом будет «Доверьтесь компилятору в выполнении его работы» и напишите код, который будет читабелен. Это подразумевает, что код логически структурирован (т.е. не содержит спагетти) и самодокументирован (т.е. достаточно четкие имена переменных, функций и т. Д.). Дополните код, который не документирован самостоятельно со значимыми комментариями. Не комментируйте ради комментирования, т.е.

x++; // Add one to x

Скорее, комментарий для вас, читатель, через 6 месяцев или 12 месяцев или какое-то другое достаточно долгое время. Принять стандарт кодирования и следовать ему.

Throwback1986
источник
+1 за «Доверяйте своему компилятору делать свою работу». Это мой новый комментарий в скайпе.
jmort253
0

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

Кроме того, современные компиляторы очень эффективно оптимизируют инструкции. Сколько строк кода вы набираете, чтобы что-то сделать, и то, что компилятор создает в терминах инструкций, не обязательно связано. Читайте о компиляторах, чтобы понять, почему это так.

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

GrandmasterB
источник
-1

Читаемость - оправдание для некомпетентных и ленивых программистов (фактически то же самое относится к «простоте», когда используется в качестве аргумента для защиты дурацкого алгоритма / дизайна)!

Для каждой конкретной проблемы вы должны стремиться к оптимальному решению! Тот факт, что современные компьютеры работают быстро, не оправдывает лишние циклы ЦП. Единственным ограничением должно быть «время доставки». Обратите внимание, что здесь «оптимальное решение» означает то, которое ВЫ можете предложить (мы не можем все предложить лучшее решение или не обладаем навыками / знаниями для их реализации).

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

Мне действительно трудно поверить, что есть программисты, которые, когда они сталкиваются с проблемой, которую они думают в строках "... это должно быть сделано так, но я сделаю так, что это будет менее эффективным, но более читабельным / ремонтопригодна и прочая такая хрень ... ». Ошибка заключается в том, что следующий разработчик (видя неэффективность), скорее всего, изменит код, а следующий сделает то же самое и т. Д. Конечный результат состоит в том, что после нескольких версий код станет тем, чем оригинал Разработчик должен был написать в 1-м месте. Единственным оправданием для первоначального разработчика является. он / она не думал об этом (достаточно справедливо) и (как упоминалось ранее) b. временные и ресурсные ограничения.

кто то
источник
-2

если снижение читабельности помогает повысить производительность / оптимизацию кода (как в swfobject и других библиотеках js), это причина просто продолжать писать хорошо отформатированный и хорошо читаемый код и преобразовывать его в нечитаемый / оптимизированный как часть процесса «компиляции» / выпуска.

www0z0k
источник