Скачать: CL | DM;

if Value = True then   Найти похожие ветки 

← →
Ega23 ©   (2009-12-22 15:13) [40]

function ConvertBooleanValue(const Value : Boolean) : Boolean;
begin
 if (Value = True) then
 begin
   Result := False;
 end
 else
   if (Value = False) then
   begin
     Result := True;
   end
   else
     raise Exception.Create("Unknown boolean value");
end;

---

← →
Mystic ©   (2009-12-22 15:15) [41]

> StriderMan ©   (22.12.09 15:02) [36]

И чем это плохо? Вообще, условие if a = b then встречается часто и никаких трудностей с его пониманием нет, нужный шаблон в мозгу срабатывает на автомате. if a then уже встречается реже.

Вообще, ход моей мысли такой: "Если a равно True", что кодируется в if a = True, потом оптимизируется до if a. При чтении кода ситуация часто обратная: if a в конце концов переходит в сознании до "Если a равно True".

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

---

← →
pasha_golub ©   (2009-12-22 15:16) [42]

> Особенно, когда название переменной не содержит явно вопроса
> (IsFile), как например в этом случае.

Вы имеете мои +100. Читабельность превыше всего!

---

← →
Медвежонок Пятачок ©   (2009-12-22 15:19) [43]

Но надо же еще сам результат сравнения аргумента с литералом сравнить на истинность.

"если условие "а равно истине" истинно"

то есть читабельнее так:
if (a = true) = true then ....

---

← →
Ega23 ©   (2009-12-22 15:20) [44]

> pasha_golub ©   (22.12.09 15:16) [42]


У тебя же было что-то такое с вариантами. Когда явно на = true нужно было сравнивать.

---

← →
Alx2 ©   (2009-12-22 15:21) [45]

if isTrueAndNothingExceptTrue((a = true) = true) then ....

---

← →
Sergey Masloff   (2009-12-22 15:21) [46]

Rouse_ ©   (22.12.09 14:23) [28]
>реализация кода в виде if B = True then говорит как минимум о не полном >предствалении корректной работы с типами переменных. Обычно авторы >такого кода используют до кучи итератор I типа DWORD, а потом долго >размышляют почему-же всетаки выполняется следующий цикл
>for I := 0 to List.Count - 1 do с учетом что List.Count реально равен нулю.
Да ну, это анекдот. Те кто уже знают про DWORD такое писать не могут ;-)

---

← →
StriderMan ©   (2009-12-22 15:22) [47]

> Но так спор из-за шести символов, которые никак не влияют на читабельность

Так из-за подобной фигни и возникают все холивары :)

---

← →
Mystic ©   (2009-12-22 15:24) [48]

Ой, до извратства можно дойти как угодно


 {$B-}
 Result := SelectDialog.Execute() and (IsDirExists(SelectDialog.Path) or CreateDir(SelectDialog.Path)) and CopyFiles(S, SelectDialog.Path);


---

← →
StriderMan ©   (2009-12-22 15:30) [49]

> Mystic ©   (22.12.09 15:24) [48]

че, очень изящно вышло ;)

---

← →
RWolf ©   (2009-12-22 15:33) [50]

> Читабельность превыше всего!

Выражение
if Form1.Visible then DoSomething;
читабельнее, чем
if Form1.Visible=True then DoSomething;

---

← →
Дуп   (2009-12-22 15:38) [51]

> Rouse_ ©   (22.12.09 14:30) [30]

Я никого не защищал!! :)

Самое интересное у нас было на семинаре по Аксапте недавно. Консультант говорит как не надо накладывать фильтр на данные и для примера как надо лезет в родной код от микрософта, а там это и сидит - неправильное. Матов было много. :)

Причем то неправильное, оно не на уровне читабельности и красивости. Там реальный косяк. Ну, и я же вроде упоминал уже как там было, что 2=1.
(1/3+1/3+1/3)+(1/3+1/3+1/3)=1.

---

← →
Дмитрий Тимохов   (2009-12-22 15:40) [52]

Оба плохо читаются, хорошо читается



if Form1.Visible=True then
  DoSomething;



---

← →
Alx2 ©   (2009-12-22 15:40) [53]

>Дуп   (22.12.09 15:38) [51]

Кэш твой - враг твой :)

---

← →
Mystic ©   (2009-12-22 15:40) [54]

> Выражение
> if Form1.Visible then DoSomething;
> читабельнее, чем
> if Form1.Visible=True then DoSomething;


Это да. Но если брать Mode вместо Form1.Visible, то мне больше нравится второй вариант. На самом деле я большинство условных операторов мысленно проговариваю, и получается нечто такое:

если Form1 видима равно True, то { хм... }
если Form1 видима, то... { нормальное предложение }
если режим то ... { хм... }
если режим установлен в True, то  { в принципе нормально }


> че, очень изящно вышло ;)


Это сокращенный вариант, в деле было пять AND-ов, внутри пару OR-ов, все работало с ShellApi функциями и оператор занимал три строки.

---

← →
Думкин ©   (2009-12-22 15:43) [55]

> Alx2 ©   (22.12.09 15:40) [53]

Мне его чистить жалко. Я тут оказывается, один пароль посеял. :(

---

← →
RWolf ©   (2009-12-22 15:43) [56]

> Дмитрий Тимохов   (22.12.09 15:40) [52]

Люди не говорят «Если форма видима — это правда, то сделай то-то».
Естественный язык звучит так: «Если форма видима — сделай то-то».

---

← →
RWolf ©   (2009-12-22 15:46) [57]

Mystic ©   (22.12.09 15:40) [54]

> Это да. Но если брать Mode вместо Form1.Visible, то мне
> больше нравится второй вариант.


Это потому, что для переменной Mode выбрано плохое имя, не соответствующее её назначению.

---

← →
Дмитрий Тимохов   (2009-12-22 15:46) [58]

>>RWolf ©   (22.12.09 15:43) [56]

Читай Мистика выше - полностью согласен с ним.
Насчет визибле, может и поторопился.

---

← →
Alx2 ©   (2009-12-22 15:47) [59]

И тип! Тип - тоже! :)

---

← →
StriderMan ©   (2009-12-22 15:51) [60]

> Это потому, что для переменной Mode выбрано плохое имя, не соответствующее её назначению.

это уже другой холивар :) пусть вместо Mode будет абстрактное Value

---

← →
RWolf ©   (2009-12-22 16:40) [61]

Абстрактные идентификаторы не есть хорошо; в идеале, программа должна напоминать пересказ алгоритма человеческим языком. Спору нет, бывают случаи, когда абстрактное имя приходится к месту (или просто нельзя переименовать идентификатор), в таких случаях можно и с True/False сравнить.
Вообще, это вопрос восприятия булевых переменных. Если для человека это простое перечисление из двух абстрактных значений «True» и «False», для него, наверное, нагляднее будет сравнивать переменную с константой. Лично я воспринимаю такую переменную, как условие ветвления, и с этой точки зрения такое сравнение просто захламляет код.

---

← →
DVM ©   (2009-12-22 17:08) [62]

> StriderMan ©   (22.12.09 11:46) 


>  if Mode = True then
>
> Лично я считаю что это образчик неграмотного и безкультурного
> кода. За такое в нашем отделе принято посмеиваться и всячески
> подначивать написавшего.

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

---

← →
sniknik ©   (2009-12-22 17:46) [63]

> в некоторых подобное необходимо (типа PHP).
jet если указывать в where boolper = true запрос работает быстрее чем where boolper, хотя результат и одинаковый.
во втором случае ни индексы ни оптимизатор не работает как понимаю.

---

← →
ANB   (2009-12-22 18:05) [64]

> where boolper

В оракле такое вообще недопустимо. Обязательно должен быть символ сравнения.

---

← →
Кто б сомневался ©   (2009-12-22 18:09) [65]

> Откопал недавно в исходниках FastReport такой кусок:
>
>  if Mode = True then
>
> Лично я считаю что это образчик неграмотного и безкультурного
> кода.


В разных ситуациях, следует по разному писать. Нужно делать код как можно понятнее.
К примеру лучшим вариантов для этого кода, будет не
If mode = true then и не
if Mode then

И то и то не очень.

Лучше так

const
 GAME_MODE_ON = true;  // для примера

if Mode = GAME_MODE_ON then

---

← →
Piter ©   (2009-12-22 18:10) [66]

Удалено модератором

---

← →
Кто б сомневался ©   (2009-12-22 18:10) [67]

Здесь сразу понятно какой режим включен. Первый или второй, т.е. не нужно возвращатся и смотреть что это за Mode.

---

← →
Кто б сомневался ©   (2009-12-22 18:12) [68]

> Piter ©   (22.12.09 18:10) [66]
>
> Кто б сомневался ©   (22.12.09 18:09) [65]
> if Mode = GAME_MODE_ON then
>
> ну это ты уже параноишь.


Нет, это очень спасает в некоторых ситуациях.
Смотри допустим в мое коде реальном :

Есть метод, который принимает
RestartWindows(AShutdown: boolean);

Иначе если false рестарт.

Я пишу:

const
 SHUTDOWN = true;
begin
 RestartWindows(SHUTDOWN);

Вот для таких случаев это очень и очень удобно.

---

← →
Кто б сомневался ©   (2009-12-22 18:16) [69]

или
GetIcon(Icon: Ticon, LargeIcon: boolean);

Пишем.
const
 GET_LARGE_ICON = true;

GetIcon(vIcon, GET_LARGE_ICON);

Это конечно не сравнение if, но у меня были случае когда и при сравнении удобнее юзать подписанные константы.

---

← →
Дмитрий Белькевич   (2009-12-22 18:31) [70]


procedure TfrxEngineOptions.SetSilentMode(Mode: Boolean);
begin  
if Mode = True then
  FSilentMode := simSilent  
else    
  FSilentMode := simMessageBoxes;
end;



procedure TfrxEngineOptions.SetSilentMode(Silent: Boolean);
begin  
if Silent then
  FSilentMode := simSilent  
else    
  FSilentMode := simMessageBoxes;
end;


---

← →
Piter ©   (2009-12-22 18:37) [71]

вообще-то для этого придумали перечисляемые типы. Например:

TIconType = (itBigIcon, itSmallIcon);

пишем

GetIcon(vIcon, itBigIcon)

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

---

← →
Кто б сомневался ©   (2009-12-22 18:43) [72]

> вообще-то для этого придумали перечисляемые типы. Например:


Я знаю, но там где два значения, удобнее и практичнее использовать boolean. Не нужно ничего объявлять лишнего.
Собственно так делал и borland в своем registry и вообще часто встречается конструкция.

---

← →
Ega23 ©   (2009-12-22 18:44) [73]

procedure TfrxEngineOptions.SetSilentMode(Mode: Boolean);
const
 ar : array[0..1] of (какой-то тип данных) = (simMessageBoxes, simSilent);
begin  
 FSilentMode := ar[Ord(Mode)];
end;


---

← →
Mystic ©   (2009-12-22 18:48) [74]


procedure TfrxEngineOptions.SetSilentMode(Mode: Boolean);
const
ar : array[Boolean] of (какой-то тип данных) = (simMessageBoxes, simSilent);
begin  
FSilentMode := ar[Mode];
end;

??

---

← →
Mystic ©   (2009-12-22 18:49) [75]

Только вместо ar лучше какой-нить SimTable

---

← →
GDI+   (2009-12-22 18:50) [76]

> StriderMan ©   (22.12.09 11:46)
>
> Откопал недавно в исходниках FastReport такой кусок:
>
>  if Mode = True then


Писал бывший сишник, так как в C есть true и TRUE.

---

← →
Rouse_ ©   (2009-12-22 18:54) [77]

>
> Писал бывший сишник, так как в C есть true и TRUE.

Ааа, а там видимо уже отменили if (B) {} или if (!B) {}

---

← →
RWolf ©   (2009-12-22 18:58) [78]

> Mystic ©   (22.12.09 18:48) [74]


Лучше всё же так:
procedure TfrxEngineOptions.SetSilentMode(Mode: TSilentMode);
begin  
FSilentMode := Mode;
end;

---

← →
Piter ©   (2009-12-22 19:02) [79]

Кто б сомневался ©   (22.12.09 18:43) [72]
Я знаю, но там где два значения, удобнее и практичнее использовать boolean

твой вариант:

GET_LARGE_ICON = true;
GET_SMALL_ICON = false;

мой вариант:

TIconType = (itSmall, itBig);

чем твой вариант удобнее, поясни пожалуйста?

насчет практичности - что ты имел в виду? И то и другое в памяти занимает 1 байт (если ты про это).

---

← →
Piter ©   (2009-12-22 19:04) [80]

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

TIconType = (itSmall, itBig, itVeryBig);

---

Страницы: 1 2 3 вся ветка

Скачать: CL | DM;



Память: 0.62 MB
Время: 0.01 c