Проверяет ли значение null значение "успех" как "двойное использование переменных"?

Ответ 1

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

"Не использовать переменные более чем для одной вещи" нацелен на такие переменные, как "temp", которые сохраняют состояние для десяти разных вещей в течение функции.

Ответ 2

Вы спрашиваете и демонстрируете 2 разных вещи.

• О чем вы спрашиваете: Использование одной и той же переменной для двух разных вещей. Например, сохраняя возраст пользователя, а также его высоту с помощью одной двойной переменной.
• Что вы демонстрируете: Использование двух переменных для этой же цели.

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

Я думаю, что корневая вещь, о которой вы спрашиваете, это: Можно ли использовать волшебное значение вместо отдельной переменной? Это зависит от вашей ситуации, но если вам гарантировано, что магическое значение (null в этом случае) не может использоваться иначе, чтобы обозначить что-то еще, тогда продолжайте.

Когда вы будете использовать первый вариант кода, который вы дали:

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

Ответ 3

Лично я бы подумал о том, чтобы переработать это в методах поиска и проверки вашего клиента, тем самым значительно сократив эту длину блока. Что-то вроде:

Customer foundCustomer = null;
if (!this.TryGetLoadedCustomer(out foundCustomer))
    foundCustomer = this.FindCustomer();

if (foundCustomer != null)
{ // ...

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

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

Ответ 4

Второй способ лучше, на мой взгляд, также. Я бы сказал, что первый способ на самом деле ошибочен, так как у вас есть две переменные, которые зависят друг от друга и дают вам избыточную информацию. Это открывает возможность их несогласованности - вы можете сделать ошибку и customerFound быть true, но foundCustomer be null. Что вы в этом случае? Лучше для этого состояния невозможно достичь.

Ответ 5

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

Ответ 6

Во втором фрагменте кода нулевое значение foundCustomer указывает, что клиент не был найден. Это звучит вполне разумно, и я бы не подумал, что это двойное использование переменной вообще.

Ответ 7

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

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

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

Ответ 8

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

Но в предложении foreach я бы добавил разрыв, если клиент найден.

НТН

Ответ 9

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

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

float x;
x=37;     // current age

if (x<50) {
    x=x/10;    // current height
    if (x>3) {
        x=3.14;    // pi to the desired level of precision
    }
}

if (x==3.14) {
   // hooray pi for everyone old enough
}
else {
    // no pi for you youngster!
}

btw, я знаю, что это просто фрагмент кода, но я не могу не думать, что с чем-то не так:

if (customerIDToFind = currentCustomer.ID)
{
    foundCustomer = currentCustomer;
}
else {
    // foundCustomer remains null
}

if (!foundCustomer) {
    // always true when currentCustomer.IsLoaded 
}

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

Ответ 10

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