Должен ли код быть коротким / лаконичным?[закрыто]

Question

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

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

В какой момент вы прекращаете сжимать программный код?

Answer 1

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

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

Answer 2

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

Например, изменение

for (int i = 0; i < n; i++)
    foo[i] = ...

Для

int * p = foo, q = foo+n;
while ( *p++ = ... < q );

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

Другим распространенным является использование bool вместо перечисления.

enum {
    MouseDown,
    MouseUp
};

Имея это быть

bool IsMouseDown;

не учитывается тот факт, что это конечный автомат, что усложняет обслуживание кода.

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

Answer 3

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

Answer 4

Вот хорошая статья Стива Макконнелла - Лучшие практики http://www.stevemcconnell.com/ieeesoftware/bp06.htm

Я думаю, что short / лаконичный - это два результата от хорошо написанного кода.Есть много аспектов, позволяющих сделать код хорошим, и много результатов от хорошо написанного кода, поймите, что это разные вещи.Вы не планируете делать маленький отпечаток стопы, вы планируете функцию, которая является лаконичной и делает одну вещь чрезвычайно хорошо - это ДОЛЖНО привести к небольшому отпечатку стопы (но может и не привести).Вот краткий список того, на чем я бы сосредоточился при написании кода:

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

Answer 5

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

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

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

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

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

Answer 6

Что касается имен объектов, то мышление по этому поводу претерпело эволюцию с появлением новых языков программирования.

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

Затем появилась санкционированная Microsoft "венгерская нотация", где первые буквы имени переменной должны были указывать на ее базовый тип.Можно было бы использовать "fLV" или что-то подобное, чтобы указать, что значение кредита было представлено переменной с плавающей точкой.

С появлением Java, а затем C # парадигма стала ясной.Хорошим названием для переменной значения кредита было бы "loanValue".Я полагаю, что одной из причин этого является функция завершения работы с командами в большинстве современных редакторов.Поскольку больше нет необходимости вводить полное имя, вы также можете использовать столько символов, сколько необходимо для описания.

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

У меня был профессор компьютерных наук, который сказал: "Как инженеры, мы постоянно создаем такие вещи, которых раньше никогда не существовало.Имена, которые мы им дадим, останутся в силе, поэтому мы должны быть осторожны, давая вещам названия осмысленно."

Answer 7

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

Answer 8

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

Когда это не удается...конечно, оставьте мне комментарий.

И не говорите мне "что" в комментарии (для этого и нужен код), скажите мне "почему".

Answer 9

В отличие от длинного / бессвязного?Конечно!

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

Answer 10

ДА.Всегда.

Answer 11

СУХОЙ:Не повторяйся.Это даст вам код, который будет одновременно кратким и безопасным.Написание одного и того же кода несколько раз - хороший способ усложнить его обслуживание.

Теперь это не означает, что вы должны создавать функцию из каких-либо блоков кода, отдаленно похожих друг на друга.

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

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

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

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

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

Answer 12

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

Answer 13

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

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

Company.get_by_name("ABC") 
makeHeaderTable()

примерно так же немногословен, как и мы.

Answer 14

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

Answer 15

На мой взгляд, есть пара моментов, которые определяют, когда следует прекратить оптимизацию:

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

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

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

Answer 16

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

Гораздо важнее, чтобы код был коротким и чистым в своей логической структуре, такой как условия тестирования, поток управления, допущения, обработка ошибок или общий программный интерфейс.Конечно, я бы также включил сюда умные и полезные комментарии + документацию.

Answer 17

Не обязательно существует корреляция между краткостью кода и производительностью.Это миф.В зрелых языках, таких как C / C ++, компиляторы способны очень эффективно оптимизировать код.В таких языках есть причина предполагать, что чем более сжатый код является более производительным.Более новым, менее оптимизированным по производительности языкам, таким как Ruby, не хватает функций оптимизации компилятора, присущих компиляторам C / C ++, но по-прежнему мало оснований полагать, что сжатый код обладает большей производительностью.Реальность такова, что мы никогда не знаем, насколько хорошо код будет работать в рабочей среде, пока он не попадет в рабочую среду и не будет профилирован.Простые, безобидные функции могут стать огромными узкими местами в производительности, если их вызывать из достаточного количества мест в коде.В высококонкурентных системах самые большие узкие места обычно вызваны плохими алгоритмами параллелизма или чрезмерной блокировкой.Эти проблемы редко решаются написанием "краткого" кода.

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

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

Мои два цента...

Answer 18

Код должно быть коротким, конкретным и концентрированным.Вы всегда можете объяснить свои идеи многими словами в Комментарии.

Answer 19

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