命名布尔字段
我为医疗环境建立了一个员工规划系统。通常，员工忙于照顾病人。有时，员工会忙于非病人护理，我喜欢在数据库中模拟这种情况。我的第一个想法是添加一个字段，例如
boolean noPatientCare default false
“但后来我想起我是多么讨厌带有否定的消息，例如“您确定不想保存此文件吗？”并想知道这样做是否会更好
boolean patientCare default true
我应该如何命名我的新专栏？这有什么理论背景吗？或者这只是一个品味问题？
I build an employee planning system for a medical environment. Normally the employees are busy with patient care. Sometimes an employee will be busy with non patient care and I like to model that situation in my database. My first thought was to add a field like
boolean noPatientCare default false
But then I remembered how I hate messages with a negation in them, like "Are you sure you don't want to save this file?" and wondered if it would be better to make it like this
boolean patientCare default true
How should I name my new column? Is there any theoretical background on this or is it just a matter of taste?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我发现如果变量表示肯定命题而不是否定命题，则条件和逻辑语句更容易阅读和理解。考虑：
与
I find conditional and logical statements easier to read and understand if variables mean positive propositions, and not their negations. Consider:
versus
这是品味和可读性的问题。
你还可以找到另一个词或概念。例如，也许不与患者一起工作的医务人员可以说是在从事行政或杂项任务。
It is a matter of taste and readability.
And you could find another word or concept. For instance, perhaps a medical worker not working with a patient could be said to work on administrative or miscellaneous tasks.
我通常会尝试避免布尔变量名称中的否定。
我曾经写过一个使用如下方法违反这条规则的好例子：
该参数实际上被称为
negate，如果你想真正“否定”>frobnicate调用您将编写frobnicate(true)。 “肯定的”frobnicate调用将是frobnicate(false)。后来读这段代码真是令人费解。如果可以的话，避免它。然而，在某些情况下，行话和/或环境可能会规定一个特定的单词，并将其更改为非否定形式实际上可能会使您的代码更难理解。
I'd generally try to avoid negation in boolean variable names.
I've once written a good example of violating this rule with a method like this:
The argument was actually called
negateand if you wanted to actually "negate" thefrobnicatecall you'd writefrobnicate(true). The "positive"frobnicatecall would befrobnicate(false). Reading this code afterwards was a formidable brain-twister. Avoid it, if you can.I some cases, however, the jargon and/or environment might dictate a specific word and changing that to be in the non-negated form might actually make your code harder to understand.
区分布尔值 0/1（护理/不护理）和两种状态 A/B（患者护理/非患者护理）。
固有的负面因素是不好的。如果命名约定暗示否定，而实际上没有否定，那就更糟糕了。所以绝对不是
noPatientCare因为这表明忙于病人护理或无人照顾。使用非病人护理意味着不同的职业。不过，如果这是一个三态
patentCare/nonpatentCare/unoccupied（或其他），则使用 enum，而不是 bool 并将字段命名为通用属性 (careOccupation)，不是值之一。如果它是严格的两种状态，那么就没有理由不能“通常为真”boolean PatientCare default true。即便如此，在选择 bool 而不是 enum 之前还是要三思而后行。您完全确定不会出现新的单独类别，或者其中一个类别不会被分成更狭窄的子类别吗？当“true”和“false”之间的区别不明显时，为字段和描述性值名称选择一个集体名称可能绝对值得，而不是使用 bool。
我的工作示例：workMode==NIGHT_MODE 或 workMode==DAY_MODE，与 bool dayWorkMode。使用
if(!dayWorkMode)为夜间操作编写特殊异常会感觉很尴尬，因为夜间并不是缺少条件，而是条件不同。Differentiate between boolean 0/1 (care/no care) and two-state A/B (patient care / nonpatient care).
Inherent negatives are bad. Naming conventions that suggest negative where there is none are worse. So definitely not
noPatientCarebecause this would suggest occupied with patient care or unoccupied. UsingnonpatientCareimplies a different occupation.Still, if this is a three-state
patientCare/nonpatientCare/unoccupied(or other) then use enum, not bool and name the field for the generic property (careOccupation), not for one of the values. If it's a strictly two-state, there is no serious reason why it can't be "usually true"boolean patientCare default true.Even then think twice before choosing bool over enum for this pick. Are you completely sure there won't be a new separate category, or that one of the categories won't be split into more narrow subcategories? It may be definitely worth picking a collective name for the field and descriptive value names than going with bool when the distinction between "true" and "false" is not apparent.
Example from my work: workMode==NIGHT_MODE or workMode==DAY_MODE, vs bool dayWorkMode. Coding special exceptions for night time operation with
if(!dayWorkMode)would feel awkward as night time is not some lack of condition, just a different condition.