Вы предпочитаете краткость или удобочитаемость в вашем коде? [закрыто]

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

Например, троичные и нулевые операторы объединения могут уменьшить объем кода, но, возможно, в ущерб удобочитаемости:

В C #:

Person newGuy = new Person();
if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
} else {
    newGuy.Boss = boss;
}

функционально эквивалентно:

Person newGuy = new Person();
newGuy.Boss = boss ?? GetDefaultBoss();

но, очевидно, гораздо более многословный.

Где вы проводите черту, когда речь идет о краткости и читабельности?

И то и другое.

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

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

Теперь сопоставьте это:

if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
    newGuy.IsTemp = true;
    newGuy.AddTask("orientation");
} else {
    newGuy.Boss = boss;
    newGuy.IsTemp = false;
}

...с:

newGuy.Boss = boss ?? GetDefaultBoss();
newGuy.IsTemp = boss == null;
if ( boss == null ) newGuy.AddTask("orientation");

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

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

Я бы сказал, что ваш пример улучшает читабельность и краткость. Рассмотрим, однако:

if( a > b )
{
    foo = bar
}
else
{
    if( c.isThing() ){
        foo = somethingElse;
    }
    else{
        foo = someFurtherThing.GetFoo();
    }
}

в отличие от

foo = a > b ? bar ?? whatever.something : c.isThing() ? somethingElse : someFurtherThing.GetFoo();

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

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

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

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

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

В принципе, если это излишне сложно понять, не делайте этого.

Читаемость стоит на первом месте, когда она конфликтует с краткостью, потому что код модифицируется чаще, чем изначально написано. С другой стороны:

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

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

Один аспект, о котором я не думаю, уже упоминался: каковы ваши цели?

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

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

_{^{Примечание: вышеизложенное не касается вас лично, @Damovisa; это для любого, выбирающего между двумя положениями.}}

Есть одна вещь, у которой у многословной версии есть преимущество.

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

Другими словами, что бы вы хотели видеть в вашем редакторе, если хотите, чтобы ваш отладчик включился когда boss == null?

(Тем не менее, мне нравится оператор ?? -)

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

Тем не менее, краткость это то, что может способствовать читабельности. Например, в вашем вопросе второй фрагмент является и более читабельным, и более кратким.