好的,我们知道以下两行是等价的 -
(0 == i)
(i == 0)
此外,过去鼓励使用第一种方法,因为如果您不小心使用'='而不是'==',那么编译器就会给出错误消息.
我的问题是 - 在今天的一代漂亮的IDE和智能编译器中,你还推荐第一种方法吗？
特别是,当我看到以下代码时,这个问题突然出现在我脑海中 -
if(DialogResult.OK == MessageBox.Show("Message")) ...
在我看来,我绝不会推荐上述内容.任何第二意见？
我更喜欢第二个,(i == 0),因为它在阅读时感觉更自然.你问人们,"你是21岁还是以上？",不是,"21岁是否小于或等于你的年龄？"
如果你把变量放在第一个或最后一个,那么在C#中无关紧要,因为赋值不会计算为bool(或可转换为bool的东西),因此编译器会捕获任何错误,如"if(i = 0)EntireCompanyData.Delete( )"
因此,至少在C#世界中,它只是一种风格而非绝望.对于说英语的人而言,将变量放在最后是不自然的.因此,对于更易读的代码,首先变量.
如果你有一个ifs列表无法通过开关很好地表示(可能是因为语言限制),那么我宁愿看到:
if (InterstingValue1 == foo) { } else
if (InterstingValue2 == foo) { } else
if (InterstingValue3 == foo) { }
因为它可以让您快速查看需要检查的重要值.
特别是在Java中,我发现它很有用:
if ("SomeValue".equals(someString)) {
}
因为someString可能为null,所以你永远不会得到NullPointerException.如果要比较对于可能为null的对象,您知道永远不会为null的常量,则同样适用.
(0 == i)
我会一直选这个.确实,今天的大多数编译器都不允许在条件语句中赋值变量,但事实是有些人会这样做.在今天的网络编程中,我必须在系统上使用无数语言.通过使用0 == i,我总是知道条件语句是正确的,我不依赖编译器/解释器来解决我的错误.现在,如果我必须从C#跳转到C++或JavaScript,我知道我不必在代码中跟踪条件语句中的赋值错误.对于这么小的东西,并节省了这么多时间,这是一个没有脑子.
我曾经相信更可读的选项(i == 0)是更好的方法.
然后我们有一个生产错误(不幸的是),其中问题是($ var = SOME_CONSTANT)类型错误.客户开始收到适用于其他客户的电子邮件.敏感类型数据也是如此.
你可以说Q/A应该抓住它,但他们没有,这是一个不同的故事.
从那天起,我一直推动(0 == i)版本.它基本上消除了这个问题.感觉不自然,所以你要注意,所以你不要犯错误.这里根本没办法弄错.
在代码审查中有人没有反转if语句也比在某人意外地在if中分配值更容易.如果格式是编码标准的一部分,那么人们就会寻找它.人们通常不会在代码审查期间调试代码,并且眼睛似乎扫描a(i = 0)vs(i == 0).
我也是java"常量字符串".equals(dynamicString)的更大粉丝,没有空指针异常是一件好事.
你知道,我总是使用条件的if(i == 0)格式,我这样做的原因是我用C#编写了大部分代码(无论如何都会标记另一个代码)并且我先做测试我的开发方法,我的测试通常会抓住这个错误.
我曾经在商店里工作过,他们试图强制执行0 == i格式,但我觉得写作很尴尬,难以记住,它最终成为寻找低调水果的代码审稿人的饲料.
实际上,DialogResult示例是我推荐该样式的地方.如果可以看到它将if()的重要部分放在左侧.如果它位于右侧并且MessageBox有更多参数(很可能),您可能需要向右滚动才能看到它.
OTOH,我从未在"(0 == i)"风格中看到太多用处.如果你能记得把常数放在第一位,你可以记住使用两个等号,
我总是尝试使用第一种情况(0 == i),这样可以挽救我的生命几次!
京公网安备 11010802040832号 | 京ICP备19059560号-6 