Установите BOOL сразу после проверки его

я работаю через чужой кодовый и есть несколько линий, как это:Установите BOOL сразу после проверки его

if (self.aBooleanProperty) { 
    self.aBooleanProperty = YES; 
    // Do some stuff 
}

Есть ли любые пункта установить его в YES сразу после проверки его? Здесь что-то не хватает?

источник

2013-05-06 nevan king

if self.aBooleanProperty - да, только тогда он входит в цикл. – Balu

У вас ничего не пропало.Кто-то, о котором вы упоминали, не хватает большого количества – Krishnabhadra

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

if (self.aBooleanProperty) { 
    self.aBooleanProperty = YES; 
    // Do some stuff 
}

В правильно написанном коде вы ничего не пропускаете, и эта линия сеттера увеличивает оплачиваемый lin кода одного с помощью no-op.

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

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

Другая причина в том, что, традиционно, BOOL-объектив-C является прославленным char. Только это не так прославлено. Таким образом, сравнение BOOL с YES действительно опасно, потому что YES имеет явное значение.

BOOL mmmmmK = 2; // this is valid 

if (mmmmmK == YES) { /* this won't execute */ }

Вроде как при подъеме на скалу и что-то начинает падать, вы не кричите «бутылка», «башмак», «галька», или «протезом конечности», но вы всегда орут ROCK.

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

Ouch.

источник

2013-05-06 14:20:36 bbum

Это то, что я изначально думал, что проверка заключалась в том, что он установил что-то другое, кроме 'YES' или' NO'. Но, глядя на остальную часть кода, есть много отходов (установка заголовков 'UIButton' для одной строки для всех четырех состояний, повторного кода). Так что, может быть, это просто надуть код. –

Проверьте первоначальный контракт; если он выставляется по строке кода, есть ваш ответ. ;) – bbum

Я думаю, что человек неправильно написал ДА, вместо этого должен был написать НЕТ, поскольку он уже ДА, когда он проверял состояние. Или иначе нет какой-либо точки в этой строке.

источник

2013-05-06 11:06:08

Я не думаю, что они имели в виду «НЕТ». Они устанавливают «НЕТ» в центральной точке кода, когда все будет завершено. –

Это сложно сказать, не имея больше кода. Я думаю, что все согласятся, что код кажется неправильным, однако то, что мы видим, является свойством obj-c - предыдущий программист мог сделать какую-то «умную» вещь, например. возможно, что получатель aBooleanProperty устанавливает себя в NO, когда вы его вызываете.

Перед изменением кода проверьте геттеры. Это напоминает мне о schrödinbug

источник

2013-05-06 11:22:28 Sulthan

В кодексе нет объектов, полностью синтезированных. –

+1 для ссылки. – viral

если

self.aBooleanProperty = YES;

входит в фигурных скобках, он не нужен, и если это

self.aBooleanProperty = NO;

включен, то логично

источник

2013-05-06 12:07:36

Установите BOOL сразу после проверки его

ответ

Смежные вопросы