布尔值什么时候比整数更好?

发布于 2024-10-09 06:40:21 字数 412 浏览 1 评论 0原文

在大多数编程语言中,可以使用 10 来代替 TrueFalse。然而,根据我的经验,整数似乎总是更容易使用。

以下是我的意思的一些示例:

if x is True: x = False
else: x = True

vs

x = abs(x-1)

__

if x is False: a = 0
else: a = 5

vs

a = 5*x

在什么情况下布尔值比 1 或 0 使用起来更简单/更高效?

In most programming languages, 1 and 0 can be used instead of True and False. However, from my experience, integers seem to always be easier to use.

Here are some examples of what I mean:

if x is True: x = False
else: x = True

vs

x = abs(x-1)

__

if x is False: a = 0
else: a = 5

vs

a = 5*x

In what cases are booleans simpler/more efficient to use than 1 or 0?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

网名女生简单气质 2024-10-16 06:40:21

在高级语言中,您应该始终使用任何布尔内置类型作为布尔值。如果 x 为 true,但等于一个不同于 1 的值,那么您的第二个示例将很难调试,并且对于任何刚接触该代码的开发人员来说,这是一个棘手的问题 - 尤其是一个不熟悉您的编码风格。
有什么问题

x = !x;

a = x ? 5 : 0;

You should always use any boolean built-in type for boolean values in high-level languages. Your second example would be a horror to debug in the case that x is true, but equal to a value different from 1, and a tricky one to figure out for any developer new to the code - especially one not familiar with your coding style.
What's wrong with

x = !x;

or

a = x ? 5 : 0;
晚风撩人 2024-10-16 06:40:21

整数比布尔值更有效的一个例子是在关系数据库中。位列通常无法建立索引(我不一定代表该语句上的所有数据库,因此“通常”),因此如果需要索引,像tinyint 这样的东西会更有意义。

请记住,根据用途和使用它的系统,布尔值“占用更少的空间”,因为它只是一个位(取决于实现),而整数是硬件的本机字大小。 (某些系统可能对布尔值使用完整的单词,当它实际在金属上运行时,本质上不节省空间,只是为了使用简单的单词大小。)

在高级编程语言中,布尔值和 int 之间的选择实际上是更多的是代码的可读性/可支持性而不是效率。如果值确实限于“true”或“false”,那么布尔值就有意义。 (这个模型是否处于给定状态,例如“有效”,或者不是?它永远不会成为第三个选项。)另一方面,如果当前有两个选项,但可以 有一天,使用布尔值可能很诱人(即使只是“暂时”),但从逻辑上讲,使用 int (或枚举)更有意义。

在代码中做“聪明”的事情时也请记住这一点。当然,做一些快速的 int 数学运算而不是使用布尔值可能看起来更时尚、更酷,但这对代码的可读性有什么影响呢?太聪明可能会很危险。

One example where an integer could be more efficient than a boolean would be in a relational database. A bit column generally can't be indexed (I can't necessarily speak for all databases on that statement, hence "generally"), so something like a tinyint would make more sense if indexing is required.

Keep in mind that, depending on the use and on the system using it, while a boolean "takes less space" because it's just a single bit (depending on the implementation), an integer is the native word size of the hardware. (Certain systems likely use a full word for a boolean, essentially saving no space when it actually runs on the metal, just to use a simple word size.)

In high-level programming languages, the choice between a boolean and an int is really more of code readability/supportability than one of efficiency. If the values are indeed limited to "true" or "false" then a boolean makes sense. (Is this model in a given state, such as "valid," or is it not? It will never be a third option.) If, on the other hand, there are currently two options but there could be more someday, it might be tempting to use a boolean (even just "for now") but it would logically make more sense to use an int (or an enum).

Keep that in mind also when doing "clever" things in code. Sure, it may look sleeker and cooler to do some quick int math instead of using a boolean, but what does that do to the readability of the code? Being too clever can be dangerous.

偏爱自由 2024-10-16 06:40:21

为了可读性和良好的意图,最好选择布尔值来表示真/假。

你知道你只有两种可能的选择。对于整数,事情可能会变得有点棘手,特别是当您使用 0 作为 false 而使用其他任何值作为 true 时。

使用整数表示真/假时,您可能会变得太聪明,所以要小心。

使用布尔值将使您和其他维护您代码的人在 6 个月后更加清楚您的意图。你需要使用的大脑周期越少越好。

For readibility and good intentions, it's always better to choose booleans for true/false.

You know that you have only two possible choices. With integers, things can get a bit tricky, especially if you're using 0 as false and anything else as true.

You can get too clever when using integers for true/false, so be careful.

Using booleans will make your intentions clearer to you 6 months later and other people who will maintain your code. The less brain cycles you have to use, the better.

欢烬 2024-10-16 06:40:21

我想说在你的例子中,布尔版本更具可读性(至少就你的意图而言)。这也完全取决于上下文。如果你为了进行微观优化而牺牲了可读性,那就是邪恶的。

I'd say in your examples that the boolean versions are more readable (at least as far as your intentions). It all depends on the context too. If you're sacrificing readability in an attempt to make micro optimizations, that's just evil.

半衾梦 2024-10-16 06:40:21

我不确定效率,但在很多情况下我更喜欢布尔值。

你的第一个例子可以很容易地写成 x = !xx = abs(x-1) 对我来说真的很晦涩。

另外,当使用整数时,您无法真正确定 x 是 1 还是 2 或 -5 或其他任何值。使用布尔值时,它始终只是 true 或 false。

I'm not sure about efficiency but I prefer booleans in many cases.

Your first example could be easily written as x = !x and x = abs(x-1) looks really obscure to me.

Also when using integers, you can't really be sure if x is 1 and not 2 or -5 or anything. When using booleans, it's always just true or false.

哑剧 2024-10-16 06:40:21

使用布尔值总是更有效,因为它更容易处理并且使用更少的处理/内存。尽可能使用布尔值

It's always more efficient to use Boolean because it's easier to process and uses less processing/memory. Whenever possible, use Boolean

挥剑断情 2024-10-16 06:40:21

布尔值显然只能接受真/假或 0/1,不仅如此,正如 Webnet 已经指出的那样,它们使用较少的处理能力和内存。

Booleans obviously can only accept true/false or 0/1, not only that they use less processing power and memory as Webnet has already stated.

为人所爱 2024-10-16 06:40:21

撇开性能问题不谈,我认为布尔值和整数是编程中两个根本不同的概念。布尔值代表条件,整数代表数字。如果您不严格保留整数布尔值 0 或非 0,则很容易引入错误,并且当您可以只使用允许编译时安全/类型检查的布尔值时,为什么还要费心呢?我的意思是,采用一个方法:

doSomething(int param)

该方法本身并不/不/意味着参数被解释为布尔值。没有人会阻止我将 1337 传递给它,也没有人会告诉我如果这样做会发生什么 - 即使明确记录不要将 1337 值传递给该方法(但只有 0 或 1),我仍然可以这样做它。如果你可以在编译时防止错误,你就应该这样做。

doSomething(bool param)

只允许两个值:true 和 false,并且都没有错误。

另外,你关于为什么整数比布尔值更好的例子有点缺陷。

if x is True: x = False
else: x = True

可以写成,

x != x

而你的整数替代:

x = abs(x-1)

需要我知道:

  • x 可以有什么可能的值
  • abs() 函数做什么
  • 为什么从 x 中减去 1
  • 这实际上/做什么/。它有什么作用?

你的第二个例子对我来说也是一个大问题。

if x is False: a = 0
else: a = 5

可以写成:

a = (x) ? 5:0;

而你的整数替代方案

a = 5*x

再次要求我知道:

  • X 是什么?
  • X 可以是什么?
  • 如果 x = 10 会发生什么? -1? 2147483647?

条件太多了。使用布尔值,以获得可读性、常识性和无错误、可预测的代码。

Performance points aside, I consider booleans and integers to be two fundamentally different concepts in programming. Boolean represents a condition, an integer represents a number. Bugs are easy to introduce if you don't strictly keep the value of your integer-boolean 0 or not 0, and why bother even with that when you can just use booleans, that allow for compile-time security / typechecking? I mean, take a method:

doSomething(int param)

The method alone does /not/ imply the param is interpreted as a boolean. Nobody will stop me from passing 1337 to it, and nobody will tell me what'll happen if I do - and even if it's clearly documented not to pass the 1337 value to the method (but only 0 or 1), I can still do it. If you can prevent errors at compile time, you should.

doSomething(bool param)

only allows two values: true and false, and neither are wrong.

Also, your examples about why integers would be better than booleans are kinda flawed.

if x is True: x = False
else: x = True

could be written as

x != x

whereas your integer alternative:

x = abs(x-1)

would require me to know:

  • What possible values x can have
  • what the abs() function does
  • why 1 is subtracted from x
  • what this actually /does/. What does it do?

Your second example is also a big wtf to me.

if x is False: a = 0
else: a = 5

could be written as:

a = (x) ? 5 : 0;

whereas your integer alternative

a = 5*x

again requires me to know:

  • What is X?
  • What can X be?
  • What happens if x = 10? -1? 2147483647?

Too much conditionals. Use booleans, for both readability, common sense, and bug-free, predictable code.

诗笺 2024-10-16 06:40:21

我喜欢布尔值,它更具可读性,而且你基本上已经与用户签订了合同。

例如“这些值只能是真或假”。

I love booleans, so much more readable and you've basically forced a contract with the user.

E.g. "These values are ONLY TRUE or FALSE".

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文