Спартанское программирование

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

'Зона наилучшего восприятия' находится где-нибудь в середине.

Одно выражение на строку.

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

Я обычно нахожусь в, "короче лучший" лагерь. Ваш пример хорош:

ObjectA a = getTheUser(session.getState().getAccount().getAccountNumber());

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

obja State = session.getState();
objb Account = State.getAccount();
objc AccountNumber = Account.getAccountNumber();
ObjectA a = getTheUser(AccountNumber);

Это - компромисс:

objb Account = session.getState().getAccount();
ObjectA a = getTheUser(Account.getAccountNumber());

но я все еще предпочитаю однострочное выражение. Вот анекдотическая причина: для меня трудно перечитать и проверка на ошибки с 4 лайнерами прямо сейчас для немых опечаток; одна строка не имеет этой проблемы, потому что существует просто меньше символов.

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

Хорошее объяснение. Я думаю, что это - версия общего Деления, и Завоюйте менталитет.

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

Вот несколько подсказок, которые я люблю использовать, чтобы нарезать и поставить на карту код:

• Имена переменной: как Вы описали бы эту переменную кому-то еще в Вашей команде? Вы не сказали бы "numberOfLinesSoFar целое число". Вы сказали бы "numLines" или что-то подобное - понятный и короткий. Не притворяйтесь как специалист по обслуживанию, не знает код вообще, но удостоверяется, что Вы сами могли выяснить, какова переменная, даже если Вы забыли свое собственное действие относительно записи его. Да, это довольно очевидно, но это стоит больше усилия, чем я вижу многие кодеры, помещенные в него, таким образом, я перечисляю его сначала.
• Поток управления: Избегайте большого количества заключительных пунктов сразу (серия}'s в C++). Обычно, когда Вы видите это, существует способ избежать его. Общий падеж - что-то как

:

if (things_are_ok) {
  // Do a lot of stuff.
  return true;
} else {
  ExpressDismay(error_str);
  return false;
}

может быть заменен

if (!things_are_ok) return ExpressDismay(error_str);
// Do a lot of stuff.
return true;

если мы можем заставить ExpressDismay (или обертка этого) возвращать false.

Другой случай:

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

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

for (vector<string>::iterator a_str = my_vec.begin(); a_str != my_vec.end(); ++a_str)

намного более многословно, и требует перегруженных операторов указателя *a_str или a_str-> размер () в цикле. Для контейнеров, которые имеют быстрый произвольный доступ, следующее намного легче считать:

for (int i = 0; i < my_vec.size(); ++i)

со ссылками на my_vec [я] в теле цикла, которое не смутит никого.

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