В рассматриваемом случае и при использовании языка, позволяющего определять свои типы, не уступающие по эффективности встроенным, можно было бы просто определить типы degree и radian, и тогда можно было бы и булевый параметр убрать, и метод/функцию переименовывать не пришлось бы.
Все в сослагательном наклонении, потому-что конкретная проблема надумана, аргумент конечно же должен задаваться в радианах. Кому нужно, пусть преобразовывает градусы в радианы перед вызовом, например так:
int status = controlRod.rotate(fromDegree(30))
Хотя на Java скорее нужно будет дополнительно указать имя класса, зато код станет законченно объектно-ориентированным :
int status = controlRod.rotate(AngleConversion.fromDegree(30))
Возможно стоит добавить, что это преобразование нужно выполнять только при вводе информации от пользователя, внутри программа должна иметь дело только с радианами.
Здравствуйте, wallaby, Вы писали:
W>Так много слов для одной простой мысли:
Согласен, там словоблудие. И ведь приходится читать, чтобы убедиться, что автор не спрятал хоть какую-нибудь полувменяемую мыслишку среди строк. Но не спрятал.
Здравствуйте, wallaby, Вы писали:
W>Здравствуйте, jazzer, Вы писали:
J>>Robert C. Martin's Clean Code Tip #12: Eliminate Boolean Arguments J>>http://www.informit.com/articles/article.aspx?p=1392524
W>Так много слов для одной простой мысли: W>Вместо одной функции с булевым аргументом часто правильнее использовать две функции.
Или например:
Вместо magic number'ов правильнее использовать именованые константы или енумы.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, K13, Вы писали:
K13>>А так — согласен, enum гораздо понятнее.
IT>Или именованные параметры.
Еще можно использовать константы, примерно так:
const bool Radians = true;
...
int status = fuelRod.rotate(0.5, Radians);
Я как-то учавствовал в проекте, в котором все числа, строки и т.д. должны были предварительно определены как константы (за исключением чисел 0 и 1). Очень разумное правило.
Здравствуйте, wallaby, Вы писали:
W>Так много слов для одной простой мысли: W>Вместо одной функции с булевым аргументом часто правильнее использовать две функции.
+1
ну так одну простую мысль в голом виде высказывать бесполезно, ее уже все высказали по многу раз
А тут — наглядный пример.
В качестве иллюстрации для начинающих программеров — самое оно.
Здравствуйте, igna, Вы писали:
I>В рассматриваемом случае и при использовании языка, позволяющего определять свои типы, не уступающие по эффективности встроенным, можно было бы просто определить типы degree и radian, и тогда можно было бы и булевый параметр убрать, и метод/функцию переименовывать не пришлось бы.
+1
I>Все в сослагательном наклонении, потому-что конкретная проблема надумана, аргумент конечно же должен задаваться в радианах.
Можете выбрать любой цвет, при условии что вы выбираете черный
Не все так однозначно.
Градусы хороши своей целочисленностью.
I>Возможно стоит добавить, что это преобразование нужно выполнять только при вводе информации от пользователя, внутри программа должна иметь дело только с радианами.
см. выше.
То же, кстати, относится к доброй половине финансовых программ, где цены, вроде как, не целые, но из лучше хранить как целые или как пару целых.
I>PS. Этот автор у тебя тоже в числе экспертов?
Я *там* в качестве эксперта упоминал Глассборо — есть сомнения, что он эксперт? Тот, кого ты *там* нашел, я впервые увидел. Ладно, здесь это офтопик в любом случае.
А эта конкретная статья в RSS прилетела, посмеялся, пока читал, решил сюда запостить.
Надеюсь, что вы тоже посмеялись.
С другой стороны, хоть и смешно, но проблема реальная: во многих признанных API (в винде, например) булевские переменные летают только в путь, в результате смотришь в вызов функции с пятью true, как дурак, и пытаешься понять, что же они все означают.
Так что мысль вроде как и очевидна, да, видать, лень побеждает — bool же проще сунуть, чем целое перечисление объявлять или вообще специальный полноценный тип ваять.
Здравствуйте, jazzer, Вы писали:
J>Градусы хороши своей целочисленностью.
Ась? Полградуса тоже бывают.
J>То же, кстати, относится к доброй половине финансовых программ, где цены, вроде как, не целые, но из лучше хранить как целые или как пару целых.
Относится, но не тоже.
J>С другой стороны, хоть и смешно, но проблема реальная: во многих признанных API (в винде, например) булевские переменные летают только в путь, в результате смотришь в вызов функции с пятью true, как дурак, и пытаешься понять, что же они все означают. J>Так что мысль вроде как и очевидна, да, видать, лень побеждает — bool же проще сунуть, чем целое перечисление объявлять или вообще специальный полноценный тип ваять.
IMHO в Windows API проблема другая, многие функции этого API выполняет несколько эээ ... функций, отсюда и неприятности. А сами по себе булевые параметры ничуть не хуже, к примеру, параметров целых; и те, и другие можно перепутать. Но сторонников определять типы вроде XCoordinate, YCoordinate, XDistance и YDistance, которые нельзя просто по ошибке использовать друг вместо друга, немного.
Здравствуйте, jazzer, Вы писали:
J>То же, кстати, относится к доброй половине финансовых программ, где цены, вроде как, не целые, но из лучше хранить как целые или как пару целых.
Кстати, а что, все же есть финансовые программы, которые хранят цены как float? Никогда подобными вещами не занимался, но вроде это расхожий пример неправильного выбора типа.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, jazzer, Вы писали:
J>>То же, кстати, относится к доброй половине финансовых программ, где цены, вроде как, не целые, но из лучше хранить как целые или как пару целых.
I>Кстати, а что, все же есть финансовые программы, которые хранят цены как float? Никогда подобными вещами не занимался, но вроде это расхожий пример неправильного выбора типа.
Есть, конечно.
Зависит от задачи.
Финансовые программы очень разные бывают.
Здравствуйте, Pro100Oleh, Вы писали:
PO>В чем прелесть bool — в том что он гарантированно может хранить лишь два значения, отчего код по анализу параметра будет проще:
Если нам не помогут, то мы тоже никого не пощадим.
:
