Использует флаги очень часто в желательном коде?

Вы установили высоту #innercontainer равной 100%, но не установили ее относительно чего-либо, поэтому она примет высоту тела в этом случае. Что-то вроде этого должно помочь вам в этом:

#maincontainer {

 position:relative;
  height:500px;
  background-color:lightgrey;
}

#innercontainer {
  height:100%;
   overflow: scroll;
   overflow-x: hidden;
}

#listrow {
  positon: relative;
  height: calc(100% - 50px);
}

#headerrow {
  background-color:grey;
  height:50px;
}

В качестве sidenote, bootstrap поставляется с хорошим стилем таблицы , который, я думаю, является хорошим примером для того, что вы пытаетесь создать .

5
задан richq 30 April 2009 в 07:41
поделиться

13 ответов

Это:

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

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

var1 = condition1;

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

11
ответ дан 18 December 2019 в 05:40
поделиться

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

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

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

с:

if(DirectionIsUp) {/* do something */}
if(PowerIsOn)     {/* do something else */}
2
ответ дан 18 December 2019 в 05:40
поделиться

Что мне не нравится в флагах, так это когда они называются флагами, без каких-либо комментариев.

Например,

void foo(...){

     bool flag;

    //begin some weird looking code

    if (something)
       [...]
      flag = true; 
 }

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

Однако, если переменная flag имеет репрезентативное имя тогда я думаю, что они в порядке, если использовать их с умом (см. другие ответы).

0
ответ дан 18 December 2019 в 05:40
поделиться

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

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

if (condition1)
{
  // do something
}
0
ответ дан 18 December 2019 в 05:40
поделиться

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

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

7
ответ дан 18 December 2019 в 05:40
поделиться

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

4
ответ дан 18 December 2019 в 05:40
поделиться

Сначала в общем, этот код должен выглядеть следующим образом:

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();
}

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

2
ответ дан 18 December 2019 в 05:40
поделиться

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

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

2
ответ дан 18 December 2019 в 05:40
поделиться

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

2
ответ дан 18 December 2019 в 05:40
поделиться

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

var $isNewRecord;
var $hasUpdated;

if ($isNewRecord)
{
}

if ($hasUpdated)
{
}
1
ответ дан 18 December 2019 в 05:40
поделиться

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

var1 = condition1

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

user_is_on_fire = condition_that_holds_when_user_is_on_fire

Это позволяет объяснить, что значит использовать условие, что часто не очевидно из голого условия.

Если оценивать условие дорогое (или имеет побочные эффекты), может быть также желательно хранить результат локально, а не переоценивать условие.

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

D'A

0
ответ дан 18 December 2019 в 05:40
поделиться

Называйте его флажками, когда вы работаете на языке до OO. Они полезны для параметризации поведения фрагмента кода.

Однако вскоре вам будет трудно следовать коду. Было бы легче читать / изменять / поддерживать, если вы абстрагируете различия, например, предоставляя ссылку на изменяемую функциональность.

В языках, где функции являются первоклассными гражданами (например, Javascript, Haskell, Lisp, ...), это очень просто.

В языках OO вы можете реализовать некоторые шаблоны проектирования, такие как Abstract Factory, Strategy / Policy , ...

Слишком много переключателей, которые я лично считаю запахом кода.

0
ответ дан 18 December 2019 в 05:40
поделиться

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

Рассмотрим, например, следующее:

def checkCondition():
  import __builtin__ as cached
  try:
      return cached.conditionValue
  except NameError:
      cached.conditionValue = someSlowFunction()
      return cached.conditionValue

Что касается стиля кодирования:

 if (условие1)
 var1 = true
еще
 var1 = false

Я ненавижу такой код. Это должно быть либо просто:

var1 = condition1

, либо, если вы хотите убедиться, что результат является логическим:

var1 = bool(condition1)

if (var1 == true)

Опять. Плохой стиль кодирования. Это:

if (var1)
0
ответ дан 18 December 2019 в 05:40
поделиться
Другие вопросы по тегам:

Похожие вопросы: