Есть ли причина писать краткий код на Java / C # / C ++?

Question

Вы когда-нибудь писали краткий код на Java, C # или C ++?

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

Answer 1

Это зависит от вашего определения «кратко».

Если вы имеете в виду «коротко и точно», это близко соответствует моему видению хорошего кода.

Если вы имеете в виду «загадочный», значит, есть проблема.

Answer 2

Код должен быть как можно более кратким и не более. :)

Замечания Беглого, кроме нескольких факторов, влияющих на то, насколько кратким (или иным образом) должно быть:

• Lifespan.

  • Часто дольше, чем вы думаете :)

• Вероятность ошибок.

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

• Компьютеры, читающие (разбирающие) его.

  • Не только компилятор, думаю, intellisense и тому подобное.

• Люди читают это

  • иногда необработанный, иногда с помощью таких программ, как diff инструменты.
  • иногда не тот человек, который это написал.

• Требуемые эксплуатационные характеристики.

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

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

Прежде всего, давайте возьмем легкие биты:

Компьютеры.

Когда они читают ваш код, они вполне способны сделать это независимо от многословия. Они могут быть немного медленнее, но это то, что обычно трудно измерить (маловероятно, что вы превысите 1 или два порядка многословия, чем минимальная теоретическая возможность). Известные исключения - это когда вы (ab) используете что-то вроде метапрограммирования через препроцессор, чтобы сделать для вас множество расширений. Это может занять long время при компиляции. Здесь вы должны решить, стоит ли этот компромисс.

Humans.

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

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

Lifespan

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

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

Производительность

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

Общие понятия

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

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

Вывод типа является мощным, но помните, что компилятор иногда намного лучше, чем человек. Если вы говорите flibble x = new flibble(), то var x = new flibble() вовсе не растягивается (и становится лучше по мере того, как flibble становится больше). Сравните с var flibble = SomeMethodWhoseReturnTypeIsNotClear(). Здесь помогает здравый смысл, если вам никогда не придется использовать intellisense для его решения, вам, безусловно, следует рассмотреть возможность его использования.

Некоторые другие полезные (и краткие) эмпирические правила:

• Несколько действий в одной строке часто сбивают людей с толку.
• Побочные эффекты часто смущают людей (например, ++ x или x ++ вообще не имеют значения, если не являются частью более широкого выражения)
• Отступ помогает большинству людей вывести структуру гораздо больше, чем скобки
• Правила приоритета часто «усваиваются» людьми, а не запоминаются как набор правил. Это означает, что ненужные (для компилятора) брекетинг может быть вреден для читабельности, где идиома распространена, но полезна, когда использование не так распространено.
• Логически не часто это один символ. При использовании этого в операторе if подумайте, можно ли его реструктурировать, чтобы он не требовался. Это может быть невозможно (если результирующие искажения имени переменной / метода или порядка кода перевешивают удаление, оставьте его в этом)

Answer 3

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

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

Foo x = null;
if (condition)
{
    x = y;
}
else
{
    x = z;
}

более или менее читабельно, чем:

Foo x = condition ? y : z;

Хорошо, если "условие", "у" и "z" все довольно просты, условный оператор побеждает. Если вам нужно пройти через обручи, чтобы сделать отдельные выражения "y" и "z", где выполнение нескольких операторов было бы более читабельным, тогда форма if / else, вероятно, будет более читабельной.

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

Answer 4

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

var result = GetResultFromFoo(GetOtherResult()).DoSomeCalculation(CallAnotherMethod());

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

var result = GetOthereEsult();
var fooResult = GetResultFromFoo(result);
var anotherMethodResult = CallAnotherMethod();
var finalResult = fooResult.DoSomeCalculation(anotherMethodResult);

Гораздо проще отлаживать.

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

Answer 5

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

Почему? Потому что через 6 месяцев вам нужно будет понять, чего вы пытались достичь. Чем быстрее вы сможете это сделать, тем лучше.

Answer 6

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

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

Хорошо написанный код переживет вас. Стремитесь к совершенству:)

Answer 7

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

Напишите «коротко и точно», как предлагает Джоэл Кохорн.

Answer 8

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

Answer 9

Я большой поклонник кода, который я могу читать. Я видел какой-то "краткий" код, который выглядит так:

int af = yb; 
while(af<ex){af++;af*=4;}

Легко увидеть, что делается программно, но ЧТО на самом деле делается с точки зрения смысла, неясно. Я бы предпочел иметь имена переменных, которые я могу прочитать позже, чем пытаться сохранить пару символов кода и использовать краткие имена. Хороший код не всегда означает самый короткий. Хороший код - это хорошие алгоритмы, хорошая документация, хорошая ремонтопригодность. Мне все равно, как долго код, если он имеет все эти свойства, это хороший код.

Answer 10

@ j_random_hacker (пока нельзя добавлять комментарии к комментарию)

Мне случилось, что через 6 месяцев мне трудно расшифровать фрагмент кода, который я написал. Так что, действительно, эта часть имеет значение также