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

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

или
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;

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

TIconType = (itBigIcon, itSmallIcon);

пишем

GetIcon(vIcon, itBigIcon)

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

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

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

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

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

??

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

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

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

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

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

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

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

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

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

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

GET_LARGE_ICON = true; GET_SMALL_ICON = false;

мой вариант:

TIconType = (itSmall, itBig);

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

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

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

TIconType = (itSmall, itBig, itVeryBig);

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