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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

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

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

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

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

enum {
    MouseDown,
    MouseUp
};

Имея это be

bool IsMouseDown;

не учитывает тот факт, что это конечный автомат, что затрудняет сохранение кода.

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

Да. Всегда.

Ответ 11

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

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

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

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

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

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

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

Ответ 12

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

Ответ 13

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

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

Company.get_by_name("ABC") 
makeHeaderTable()

примерно такая же кратка, как и мы.

Ответ 14

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

Ответ 15

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

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

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

Ответ 16

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

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

Ответ 17

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

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

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

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

Ответ 18

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

Ответ 19

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