Является ли использование флагов очень часто в коде целесообразным?

Question

Я наткнулся на множество флагов, читая чужой код,

if (condition1) 
    var1 = true
else
    var1 = false

потом,

if (var1 == true)
    // do something.

Есть много таких флагов. Я хочу знать, часто ли в коде рекомендуется использовать флаги?

Answer 1

Это:

if (condition1)
   var1= true;
else
   var1 = false;

Классический плохо написанный код.
Вместо этого вы должны написать:

var1 = condition1;

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

Answer 2

Рекомендуется, если condition1 является чем-то довольно сложным - например, if (A && (B || C) && !D) или содержит много служебных данных (if (somethingTimeConsumingThatWontChange())), тогда имеет смысл сохранить этот результат вместо копирования кода.

Если condition1 - это простое сравнение, то нет, я бы не использовал флаг.

Answer 3

Это довольно субъективно и зависит от остальной части кода. «Флаги», как вы их называете, имеют свое место.

Answer 4

Флаги очень полезны, но дают им разумные имена, например, используя «Есть» или похожие в их именах.

Например, сравнить:

if(Direction)    {/* do something */}
if(PowerSetting) {/* do something else */}

с:

if(DirectionIsUp) {/* do something */}
if(PowerIsOn)     {/* do something else */}

Answer 5

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

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

Answer 6

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

Answer 7

Прежде всего, этот код должен читаться так:

var1 = condition1;

if( var1 )

// No need to compare *true* to *true* when you're looking for *true*

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

var methodName = someFunctionThatReturnsAString();

// assuming you name the method according to what's returned
myObject[ methodName ]();

вместо

if( someFunctionThatReturnsAString === 'myPreferedMethod' ){
    myObject.myPreferedMethod();
}else{
    myObject.theOtherMethod();
}

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

Answer 8

Если он читается и выполняет работу, то в этом нет ничего плохого. Просто используйте префикс «has» и «is», чтобы сделать его более читабельным:

var $isNewRecord;
var $hasUpdated;

if ($isNewRecord)
{
}

if ($hasUpdated)
{
}

Answer 9

Вот мой дубль. Код с использованием флагов:

...
if (dogIsBarking && smellsBad) {
  cleanupNeeded = true;
}
doOtherStuff();
... many lines later
if (cleanupNeeded) {
  startCleanup();
}
...

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

...
doOtherStuff();
... many lines later
if (dogIsBarking && smellsBad) {
  startCleanup();
}
...

И, следуя совету Роберта Мартина (Чистый код), может преобразовать логику в более осмысленный метод:

...
doSomeStuff();
... many lines later
if (dogTookADump()) {
  startCleanup();
}
...
boolean dogTookADump() {
  return (dogIsBarking && smellsBad);
}

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

Answer 10

Да, это просто глупый бессмысленный код.

Вы можете упростить все это до:

if (condition1)
{
  // do something
}