如果我只想检查某些内容是否不可能（即我不会使用if(possible)之类的东西），我应该将布尔值命名为notPossible并使用if(notPossible)或我应该将其命名为possible并改为使用if(!possible)吗？
只是为了确定，如果我还要检查它是否为possible，我会将布尔值命名为if(possible)和else，对吗？
答案 0 :(得分：6)
您应该使用isPossible。
像notPossible这样的布尔值的否定名称是一个非常糟糕的主意。您可能最终必须编写if (!notPossible)之类的内容，这会使代码难以阅读。不要那样做。
答案 1 :(得分：4)
我倾向于在积极性方面犯错并使用possible。这意味着有人不能在以后编写一些代码......
if (!notPossible)
这是不可读的。
答案 2 :(得分：1)
我喜欢用一致的短动词前缀来命名布尔值，例如is或has，并且我会发现一个特殊而且难以精神化“解析”的not前缀（所以我怀疑，很多代码的读者，无论是否有这种感觉;-) - 所以，我要么命名变量isPossible（并使用!isPossible），或者只是将变量命名为isImpossible（许多形容词都有这样的方便反义词，对于前缀has，您可以使用前缀lacks来制作整个事物的反义词; - ）。
答案 3 :(得分：1)
我通常会尝试命名我的旗帜，以便他们尽可能好地阅读它们的使用位置。这意味着尝试命名它们，以便它们在使用它们时不必被否定。
我知道有些人坚持认为所有的名字都是正面的，这样人们就不会对名字中的否定和头脑中的否定感到困惑。对于类接口中的布尔值，这可能是一个很好的策略。但如果它本地到一个源文件，并且我知道所有的调用都会否定它，我宁愿看到if (impossible && ...)而不是if (!isPossible && ...)。
答案 4 :(得分：0)
在您的特定应用程序中更容易阅读。请确保你最终没有“if（！not possible）”。
答案 5 :(得分：0)
我认为最好避免在变量名中使用否定词，这样就可以避免if（！notPossible）的双重否定。
答案 6 :(得分：0)
我建议使用isPossible。在命名布尔变量时，只要能够使用'is'（或者可能是'has'）似乎很有意义。这是合乎逻辑的，因为你想知道是否可能，对吧？
答案 7 :(得分：0)
我同意负面命名的布尔是一个坏主意，但有时可能以一种积极的方式重新构建条件。例如，您可以使用pathIsBlocked而不是cannotProceed，或者使用isIotAbleToDie而不是isImmortal。
答案 8 :(得分：0)
您应该将其命名为确切存储在其中的内容。如果您要存储是否可能，请将其命名为isPossible。如果您要存储是否不可能将其命名为isImpossible。
如果您需要检查两种情况，您可以使用else。
根据您的描述，检查不可能性对您来说更重要，所以我选择isImpossible：
if(isImpossible)
{
// ...
}
else
{
//...
}