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

вы когда-нибудь обнаружили, что пишете краткий код на Java, C# или c++?

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

6
c# coding-style java

12 ответов

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

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

  • продолжительность жизни.

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

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

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

  • чтение компьютеров (разбор).

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

  • люди, читающие это

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

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

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

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

во-первых, давайте возьмем простой биты:

компьютеры.

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

людей.

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

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

продолжительность жизни

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

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

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

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

общие Понятия

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

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

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

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

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

Это зависит от вашего определения 'немногословный'.

Если вы имеете в виду "короткий и по существу", это близко соответствует моему видению для хороший код.

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

23

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

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

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

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

Foo x = condition ? y : z;

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

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

12

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

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

4

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

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

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

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

гораздо легче отлаживать.

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

4

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

2

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

напишите "коротко и по существу", как предлагает Джоэл Кохорн.

2

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

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

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

2

@j_random_hacker (пока нет комментариев к комментариям)

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

1

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

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

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

1

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

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

в противном случае, Краткий (в смысле "к точке") код лучше, чем подробный код.

0

есть один механический недостаток для подробного кода и именования в java: объем памяти под некоторыми JVMs. Это может быть только проблема восприятия вокруг виртуального размера процесса и сопоставленных с памятью файлов jar, но она существует. Big jar files = = использование большой (воспринимаемой) памяти.

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

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

0