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

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

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

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

Твои мысли?

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

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

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

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

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

Иногда да.

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

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

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

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

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

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

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

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

Уэс Дайер

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

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

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

На мой взгляд, нет абсолютно никаких оправданий, чтобы не иметь несколько основных комментариев. Очевидно, что 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
    ; ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

x++; // Add one to x

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

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

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

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

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

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

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

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

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