Булевы значения более логично было бы обозвать не "да" и "нет", а "истина" и "ложь".
Да, изначально я так и сделал. Но потом решил поэкспериментировать. Это не окончательный вариант. Тому есть причина. Кто перешёл на .Net, тот знает, что переменные там стали классами и потому многие выражения с промверками некоторых условий стали иметь совершенно иной вид, к примеру, проверка строки на равенство другой строке записывается теперь через функцию .equals(), а ранее с процедурной парадигмой писали явно: Str2 == Str2 или if Str1 == "abc". То же в некоторой мере относится и к другим типам. Таким образом, если попробовать понимать:
если строка.
equals(строка2) == истина { } - это не "звучит", а вот это звучит:
если строка.
equals(строка2) ==
да { }. Я ещё не придумал замены для
equals. Мои строки (CString) в программе, как Вы заметили, тоже классы и в своём синтаксисе я бы тоже потом хотел придерживаться такого современного подхода.
Или ещё пример:
- Код: Выделить всё
Private Sub РазделительПравый_MouseMove(Button As Integer, Shift As Integer, x As Single, y As Single)
If ПравыйРазделительДвижется Then
РазделительПравый.Left = РазделительПравый.Left + x - НачX
ПанельОсновная.Width = РазделительПравый.Left
ПанельПравая.Left = РазделительПравый.Left + РазделительПравый.Width
ПанельПравая.Width = Me.ScaleWidth - ПанельПравая.Left
ОбновитьПравуюПанель
ОбновитьОсновнуюПанель
End If
End Sub
Что было бы тут уместнее? С моей точки зрения
If ПравыйРазделительДвижется =
истина Then хуже, чем
If ПравыйРазделительДвижется =
да Then. Короче говоря, много ли вы встречали абстрактных логических выражений? Я таких не припомню. Булевую переменную обычно объявляют как результат (признак) законченного или продолжающегося действия, поэтому
да и
нет звучат вполне логично. Состояние же объекта (не действия) описывать булевым типом не хорошо, для этого есть перечисления, т.к. всегда должен быть и третий вариант: не определено (не известно). Когда начинаешь программить по-русски, то приходит понимание написанного. Даже если взять работу с теми же битами:
- Код: Выделить всё
Бит7Установлен = (Bits And &H80) <> 0
' или
Бит7Установлен = ((Bits And &H80) <> 0) = да)
Тут
да и
нет сами напрашиваются.
Я посмотрел местный код другого калькулятора (обработка ошибок там, мягко говоря, слабовата, я уж не говорю про полное отсутствие идентификаторов-констант):
[Парсер] Еще один Эвалютатор мат. выраженийи, честно говоря, хотел бы направить свой код в то же русло, только у меня будет нормальный языковой синтаксис на подобии си шарпа или явы. Мой код, так скажем, слегка примитивен. По-настоящему, конечно, нужно преобразовывать выражение в ОПЗ, как делается в математических программах и, наверное, в компиляторах. Мне хочется потом перевести код в листинг на MSIL, чтобы компильнуть хотя бы в консольную прогу для .Net. А для этого мне нужно
дерево инструкций, что делается как раз при помощи ОПЗ.
Потому в будущем я слегка изменю алгоритм, чтобы разбор приводил к работе со стеком. Подумаю ещё как лучше это реализовать. Я видел один хороший пример как это сделано в программе SMath Studio и он не даёт мне покоя. Хочется одновременно простоты, понятности и чтобы можно было хотя бы консольные проги компилить, т.е. по-настоящему.
П.С. С equals() пример не совсем верный. Это из Java я взял, в C# его переопределять для этих целей надо.
Ах, да... почему же тогда используются true и false, ведь они могли бы использовать yes и no? Может быть это исторически так сложилось? Раньше ведь объектности в массе своей такой не было. Вот и привыкли.
Это даже немного смешно. Вот взять таблицу свойств компонента и пройтись по некоторым булевым свойствам:
Enabled,
HideSelection,
Locked,
Visible и т.д.
Неужели значения
истина и
ложь для них смотрятся естественно? Если реально не понимать их смысла, то всё равно, а вот если докапываться до этого, то как-то странно звучит. В MS Access для логического типа поля можно выбрать три варианта формата вывода: Истина/Ложь, Да/Нет и Вкл/Выкл.