Стоит ли жертвовать читабельностью кода тем, насколько он эффективен?
например, 3 строки кода в 1 строку.
Я прочитал в Code Craft Питом Гудлиффом, что читабельность - это ключ.
Твои мысли?
code-quality
performance
optimization
readability
TeaDrinkingGeek
источник
источник
Ответы:
«Меньше линий» не всегда то же самое, что «более эффективный». Я предполагаю, что вы имеете в виду «Должна ли программа быть короче за счет читабельности».
В целом, я думаю, что более важно, чтобы программа была понятной, а не короткой. Я должен отметить, что сокращение программы часто также делает ее более читабельной (есть очевидный порог, к которому вы попадаете, когда ваш код начинает выглядеть как шум строки, но до этого момента выражение чего-то более краткого, кажется, делает его более понятным).
Существуют особые исключения (например, ваши личные сценарии оболочки или одноразовый код для сбора данных), которые никто никогда не должен будет поддерживать, и только вам когда-либо придется читать. В этой ситуации, вероятно, можно пожертвовать некоторой читабельностью ради целесообразности, если вы все еще можете это понять.
источник
Иногда да.
Читаемость - это хорошая вещь, к которой нужно стремиться. Большая часть кода, написанного для типичных бизнес-приложений, будет достаточно производительной, и важно сосредоточиться на удобочитаемости. В областях, требующих большей производительности (таких как программирование видеоигр или тяжелые вычисления), может быть важно отказаться от читабельности в пользу использования особой языковой функции, которая ужасно нечитаема и в то же время невероятно эффективна.
Пример последнего см. В статье « Быстрый обратный квадратный корень» в Википедии.
Я вообще думаю, что лучше сначала сделать что-то читаемым, а потом беспокоиться о производительности, при условии, что приняты меры предосторожности, такие как отказ от выбора алгоритма O (n ^ 2) вместо O (n). На мой взгляд, жертвенность удобочитаемостью ради краткости ошибочна.
источник
Единственный раз, когда я пожертвовал бы удобочитаемостью, было бы, когда код, как показывали, был узким местом производительности, и переписывание исправило бы это. В этом случае намерение кода должно быть хорошо задокументировано, чтобы в случае ошибки его можно было легко отследить.
Это не говорит о том, что переписывание должно быть нечитаемым, конечно.
источник
Я цитировал это раньше , и я процитирую это снова:
Уэс Дайер
источник
Стоит ли жертвовать читабельностью кода тем, насколько он эффективен?
С точки зрения кода, всегда приятно самодокументироваться. Но иногда этого не может быть. Иногда вам нужно оптимизировать, а иногда этот код сам по себе не очень читабелен.
Для этого и были придуманы комментарии . Используй их. Даже на сборке есть комментарии. Если вы написали массу кода, а комментариев нет, я беспокоюсь. Комментарии не влияют на производительность во время выполнения, но всегда помогают несколько заметок о том, что происходит.
На мой взгляд, нет абсолютно никаких оправданий, чтобы не иметь несколько основных комментариев. Очевидно, что
if ( x == 0 ) /* check if x is 0 */
это абсолютно бесполезно; Вы не должны добавлять ненужный шум в код, но что-то вроде этого:Это довольно полезно.
источник
Стоит ли жертвовать читабельностью кода тем, насколько он эффективен?
Если эффективность - ваша текущая цель (как на этапе оптимизации), и вы знаете - у вас есть метрики, не так ли? - эта строка (и) кода является текущим узким местом, тогда да.
В противном случае no: удобочитаемость позволит вам (или другому пользователю) позже изменить этот код, чтобы сделать его более эффективным, так как его легче понять.
источник
Никто не выигрывает Code Golf
Особенно ужасная идея.
Стоимость игры в гольф-код - очень высокая.
Стоимость поддержки нечитаемых программ - астрономическая.
Значение такого вида минимизированного кода - ноль. Это все еще работает, но не работает "лучше".
Стоимость выбора правильного алгоритма и структуры данных - умеренная.
Стоимость поддержания правильного алгоритма и структуры данных - низкая.
Значение правильного алгоритма и структуры данных - высокое. Использование ресурсов невелико.
Стоимость поиграть в микрооптимизацию - высокая.
Стоимость поддержки нечитаемого, микрооптимизированного кода - очень высокая.
Ценность микрооптимизации - варьируется. Когда здесь есть ненулевое значение, затраты все равно перевешивают его.
источник
Зависит от того, говорим ли мы об эффективности с точки зрения скорости выполнения кода или эффективности о том, насколько быстро разработчик может написать код. Если вы жертвуете читабельностью кода ради возможности очень быстрого ввода кода, то вы, скорее всего, будете тратить время на отладку.
Тем не менее, если мы говорим о том, что нужно жертвовать читабельностью кода с точки зрения скорости выполнения кода, то это, вероятно, приемлемый компромисс, если код должен эффективно преформироваться. Написание чего-то, что выполняется настолько быстро, насколько это возможно, только потому, что вы можете это сделать не так хорошо, как причина, потому что это что-то вроде быстрого обратного квадратного корня, где производительность является ключевым фактором. Хитрость заключается в том, чтобы сбалансировать код и убедиться, что, хотя источник может быть трудным для чтения, комментарии, описывающие его действия, объясняют, что происходит.
источник
Многие трюки, которые должны были сделать код быстрее, но, как правило, делают код менее читабельным, больше не нужны, потому что либо компиляторы стали очень умными (даже умнее, чем большинство разработчиков), либо машины стали смехотворно быстрыми.
источник
Я не принимаю аргумент «удобочитаемость за производительность». Позвольте мне дать вам ответ с другим оттенком.
Немного предыстории: Вы знаете, что меня тошнит? Когда я дважды щелкаю на «Мой компьютер», мне приходится ждать, пока он заполнится. Если это займет больше 5 секунд, я очень расстроен. Глупо, и не просто обвинять в этом Microsoft, это то, что в некоторых случаях причина, по которой это занимает так много времени, заключается в том, что необходимо принять решение о том, какую иконку показывать! Это верно. Итак, я сижу, интересуюсь только переходом на мой диск C: и мне нужно подождать, пока драйвер получит доступ к моему CD-ROM и прочтет значок оттуда (при условии, что в приводе есть CD).
ХОРОШО. Так что на секунду представьте, что все слои между мной дважды щелкают по Моему компьютеру, и он фактически общается через драйверы с CD-ROM. Теперь представьте, что каждый слой был ... быстрее ...
Видите ли, за всем этим стоят тысячи счастливых программистов, потому что их код «более читабелен». Замечательно. Я рад за тебя. Но с точки зрения пользователя это просто отстой (технический термин). И поэтому вы спите спокойно ночью, говоря себе, что поступили правильно, убедившись, что код более читабелен и при этом медленнее. Даже немного медленнее, чем может быть. И так делают тысячи разработчиков, и мы в конечном итоге ждем наших ПК из-за вас. По моему вы не достойны. Я не говорю, что ваши самые первые строки должны быть лучшими.
Вот мой подход: сначала заставьте это работать, затем сделайте это быстрее. Всегда старайтесь писать эффективный код, и если вам нужно пожертвовать читабельностью, дополните его комментариями. Я не буду жертвовать эффективностью, чтобы какой-то посредственный программист мог ее поддерживать. Однако я объясню свой код, но если этого недостаточно, извините, вы просто некомпетентны, чтобы работать здесь. Потому что здесь мы пишем код, который является быстрым и читаемым, и хотя баланс существует, читаемый код можно объяснить, тогда как неэффективность просто недопустима.
источник
Этот вопрос часто приходил мне в голову, когда интервью обсуждали в офисе. Много лет назад, когда я был выпускником, мне был задан вопрос «Как вы думаете, код самодокументируется?». Теперь я должен был ответить на этот вопрос как программист, и что касается интервьюера, это был черно-белый вопрос, поэтому не было никакого среднего уровня. Процесс должен пережить индивидуальность, так как люди будут более чем оживленно приходить и уходить, и вы хотите, чтобы как можно скорее были готовы новые начинания, и чем проще будет прочитать код, тем быстрее он поймет, что происходит.
Некоторое время назад я прочитал довольно хорошую книгу под названием «Разработка на основе доменов: Проектирование на основе доменов: решение сложных задач в основе программного обеспечения». Конечно, вначале это немного сухое чтение, но материал хорошо представлен. Это показывает хороший подход, который приводит к системам, которые хорошо документируют себя. Язык является средой для передачи вашего решения, поэтому, чем яснее решение, тем легче адаптироваться, если производительность становится критическим фактором. Это мое убеждение, и оно, похоже, хорошо сработало для меня.
источник
Редко будет окупаемость инвестиций в ускорение кода за счет читабельности. Современные компьютеры работают так быстро, что я сомневаюсь, что будет сценарий, когда вы захотите этого. Если на компьютере выполняется код, этот код необходимо сохранить.
С этой целью я считаю читабельность очень важной. Конечно, как говорилось много раз, просто потому, что код читабелен, не обязательно означает, что он медленнее.
Хорошим примером является имя переменной:
$a
Что такое
$a
?? Это вне контекста, так что вы не можете ответить на этот вопрос, но сталкивались ли вы с этим в реальном коде? Теперь предположим, что кто-то написал$file_handle
- что это? Это понятно даже вне контекста. Длина имени переменной имеет незначительное значение для компьютера.Я думаю, что здесь есть здравый смысл.
Некоторые приложения могут требовать кратковременного сокращения, которое не все поймут, но я думаю, что в какой-то момент отдача уменьшается, и поиск сценария встречается редко *.
* это зависит от отрасли и других подобных вещей. Я смотрю на это с точки зрения разработчика программного обеспечения для бизнеса (Business Information Systems).
Чтобы взглянуть на это с еще одной точки зрения (но не на случай), я работаю в компании, которая занимается SAAS. Когда сайт закрывается, мы должны исправить это очень быстро - обычно кто-то другой исправляет код другого разработчика.
Я бы много , а кто - то сделать что - то очень неумело , но читаемый , чем сделать его фантазии и «быстро». Наши веб-серверы являются передовыми, и запрос не нужно доставлять за миллионные доли секунды. У нас нет проблем с нагрузкой.
Поэтому на практике я думаю, что вы, скорее всего, навредите себе или другим ... (Я бы предпочел, чтобы мои выходные вернулись.)
источник
В большинстве случаев ответом будет «Доверьтесь компилятору в выполнении его работы» и напишите код, который будет читабелен. Это подразумевает, что код логически структурирован (т.е. не содержит спагетти) и самодокументирован (т.е. достаточно четкие имена переменных, функций и т. Д.). Дополните код, который не документирован самостоятельно со значимыми комментариями. Не комментируйте ради комментирования, т.е.
Скорее, комментарий для вас, читатель, через 6 месяцев или 12 месяцев или какое-то другое достаточно долгое время. Принять стандарт кодирования и следовать ему.
источник
Чистый код - это быстрый код. Четко написанный, простой в обслуживании код имеет тенденцию быть быстрее, потому что это показатель того, что программист понимал задачу под рукой и реорганизовал код до его основного назначения.
Кроме того, современные компиляторы очень эффективно оптимизируют инструкции. Сколько строк кода вы набираете, чтобы что-то сделать, и то, что компилятор создает в терминах инструкций, не обязательно связано. Читайте о компиляторах, чтобы понять, почему это так.
Когда я работаю над чем-то, основанным на производительности, например за графикой, я иногда жертвую удобочитаемостью / удобством обслуживания, когда занимаюсь такими вещами, как обработка изображений, когда я работаю над самым глубоким из вложенных алгоритмов, где небольшая оптимизация может оказать существенное влияние. И даже тогда я делаю это только после профилирования, чтобы убедиться, что изменения действительно ускоряют процесс. Я не могу сказать вам, сколько раз я пробовал «оптимизации» с ручным кодированием, но обнаружил, что это на самом деле замедляет работу приложения из-за того, как компилятор оптимизировал код, набранный вручную.
источник
Читаемость - оправдание для некомпетентных и ленивых программистов (фактически то же самое относится к «простоте», когда используется в качестве аргумента для защиты дурацкого алгоритма / дизайна)!
Для каждой конкретной проблемы вы должны стремиться к оптимальному решению! Тот факт, что современные компьютеры работают быстро, не оправдывает лишние циклы ЦП. Единственным ограничением должно быть «время доставки». Обратите внимание, что здесь «оптимальное решение» означает то, которое ВЫ можете предложить (мы не можем все предложить лучшее решение или не обладаем навыками / знаниями для их реализации).
Как кто-то еще упомянул, если есть «трудные для понимания» аспекты решения, для этого и нужны комментарии. Порядок «правильный, читаемый, быстрый» (или что-то в этом роде), о котором кто-то упомянул, - просто трата времени.
Мне действительно трудно поверить, что есть программисты, которые, когда они сталкиваются с проблемой, которую они думают в строках "... это должно быть сделано так, но я сделаю так, что это будет менее эффективным, но более читабельным / ремонтопригодна и прочая такая хрень ... ». Ошибка заключается в том, что следующий разработчик (видя неэффективность), скорее всего, изменит код, а следующий сделает то же самое и т. Д. Конечный результат состоит в том, что после нескольких версий код станет тем, чем оригинал Разработчик должен был написать в 1-м месте. Единственным оправданием для первоначального разработчика является. он / она не думал об этом (достаточно справедливо) и (как упоминалось ранее) b. временные и ресурсные ограничения.
источник
если снижение читабельности помогает повысить производительность / оптимизацию кода (как в swfobject и других библиотеках js), это причина просто продолжать писать хорошо отформатированный и хорошо читаемый код и преобразовывать его в нечитаемый / оптимизированный как часть процесса «компиляции» / выпуска.
источник