Принципы программирования: назначение против условий

Question

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

int delta = 0;
if (some_condition)
    delta = 42;

x1 = regular_value1 + delta;
x2 = regular_value2 + delta;
// ...
// where delta is used a lot of times
// basically - if (some_condition == true) => add delta to all variables
// if FALSE - add 0 (thus, effectively not changing anything)

против

int delta = 42;

if (some_condition)
{
    x1 = regular_value1 + delta;
    x2 = regular_value2 + delta;
    // ...
}
else
{
    x1 = regular_value1;
    x2 = regular_value2;
    // ...
}

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

I 'Я программирую игру на C # XNA (поэтому производительность в некоторой степени важна, но принципы ООП ни в коем случае не должны быть опущены), поэтому мой вопрос - какой код будет работать быстрее при условии, что «some_condition» будет TRUE в 50% времени?Кроме того, какой блок кода легче поддерживать / читать?

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

Спасибо.

Answer 1

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

Но второе решение будет быстрее, особенно если "дельта "превращается в постоянную.Если «some_condition» имеет значение false, добавление не требуется, и optmizer может найти способ ускорить фактические назначения, так что я вижу преимущество в производительности.Я думаю, что лучше всего написать самый быстрый код, который вы можете, если вы не повредите удобству обслуживания.Даже с чем-то с гораздо большей разницей в производительности, чем эта, вы реально никогда не вернетесь позже в поисках способов ускорить это.Вы можете также написать код производительности и забыть об этом.Продолжайте в том же духе, и ваш код будет работать быстрее без каких-либо затрат для вас.

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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