Java boolean getter "is" vs "are"
Posted
技术标签:
【中文标题】Java boolean getter "is" vs "are"【英文标题】:Java boolean getters "is" vs "are" 【发布时间】:2012-10-09 06:13:53 【问题描述】:我知道 Java 中布尔 getter 的约定是包含前缀“is”。
isEnabled
isStoreOpen
但是如果主语是复数呢?也就是说,如果我不想知道一家商店是否营业,而是想知道所有商店是否都营业,该怎么办?
isStoresOpen()
在英语中没有意义。
我很想写像这样的吸气剂:
areStoresOpen
areDogsCute
areCatsFuzzy
我认为这是有道理的,但其他人告诉我,我应该接受它并放弃主语动词协议并使用isStoresOpen
、isDogsCute
、isCatsFuzzy
。
无论如何,对于在复数主题上操作的布尔 getter,我应该怎么做?
【问题讨论】:
我从未见过are*()
getter。
如果语法正确,我总是写 are*()
getter。
如果你的对象是一个bean,我认为你必须坚持is
或has
...
如果您使用的是 are*() getter,那么我认为在大多数情况下它应该返回 boolean[]。
通常情况下,将复数的“all”变成单数的“any”并得到否定的结果(例如德摩根定律)并不难。 areAllStoresClosed()
--> isAnyStoreOpen()
或 areAllStoresOpen()
--> isAnyStoreClosed()
【参考方案1】:
有足够的英语并遵循 Java 标准怎么样:
isEveryStoreOpen()
或 isEachCatCute()
当我对正确的词有疑问时,我总是喜欢查询词库。
【讨论】:
+1,这清楚地传达了返回值是指 isEveryStoreOpen() 还是 isAnyStoreOpen(),这与模棱两可的 isStoresOpen() 不同。 +1 这应该是公认的答案!在保持 Javaboolean
s is
前缀约定的同时在语法上有意义。此外,它还提供了一些额外的信息,对于那些碰巧是代码库维护者的非英语母语人士真正很有用。
这个答案改变了我的生活!它应该是公认的答案。
是的,但是你如何表达一个变量名称来传达以下信息:“有些 [不是所有] 商店都营业吗”?
isAnyCatCute()
或 isAtLeastOneCatCute()
怎么样?【参考方案2】:
我不记得这是出自哪本书,但本质是代码的阅读次数比编写次数要多得多。为了可读性而写。
【讨论】:
清洁代码 - 罗伯特·马丁 John B:我没看过那本书;也许我读过它的参考。不过,我名单上的另一本书。 :) 但要非常小心,不要走得太远。storesAreOpen()
可能是最符合语法的(因为 if(storesAreOpen())
),但是名称的布尔部分现在隐藏在方法名称的中间,这违反了 Java 约定 和 可读代码。
他以非常笼统的方式回答了这个问题。确实,他没有解决具体问题,但这是一个答案。它可能看起来很老套,但它很有价值(至少有 24 人这么认为)。
为了澄清答案,我要补充一点 areStoresOpen() 是一个不错的选择。【参考方案3】:
惯例是在 getter 方法前加上“is”而不是变量本身。
例如
private boolean enabled;
public boolean isEnabled()
return enabled;
和
private boolean storesOpen;
public boolean isStoresOpen()
return storesOpen;
isStoresOpen() 在英语中没有意义。
它在语法上可能没有意义,但它遵循约定并且看起来足够可读。
【讨论】:
你的回答很有道理,我很感激。我认为从权威的正确/错误立场来看,您是对的。我只是不希望一个旨在通过明显、清晰和易于理解来帮助我们的约定为了遵守其规则而放弃该目的。但你是对的——事情就是这样,这就是我问的问题。 @kodai:我认为这不应该被视为规则,而只是一种惯例。但我相信,虽然编写代码不遵循约定,但如果不需要,让代码可读是要走的路。【参考方案4】:Java Bean 规范要求使用 get
作为 getter,除非它是 boolean
,然后使用 is
。 are
是非标准的,不会被任何期望标准 Bean 命名的东西识别。
【讨论】:
【参考方案5】:很多工具都需要is
或get
,但不太可能识别are
。
尝试改写它们,例如 getDogsAreFuzzy()
或 getStoresAreOpen()
或类似的东西,以获得更好的兼容性和约定。
【讨论】:
是的。 bean 实用程序等工具依靠单词 is 来查找布尔 getter。【参考方案6】:您编写什么代码,English 还是 Java?
当我阅读 Java 代码时,我希望事情是结构化的。以is
开头的布尔方法是一个很好的结构。
return 0;
【讨论】:
【参考方案7】:- isEnabled()
也可以写成getEnabled()
Java naming conventions
。
- 遵循命名约定只是一个好习惯,在您使用Java Beans
时会有所帮助。
【讨论】:
【参考方案8】:总的来说,我认为代码应该尽可能易于阅读,这样一个方法几乎可以作为一个段落来阅读(正如Clean Code
所支持的那样)。因此,我将命名该方法以尽可能容易地发声/阅读,并遵循are
的语法规则。使用现代 IDE,无需专门查找 get
/ is
即可轻松找到方法。
不过,Kumar 对豆类提出了一个很好的观点。很多工具只会寻找get
/ is
。在那种情况下,我可能会考虑两种方法。一种便于阅读,一种用于工具使用。
【讨论】:
【参考方案9】:在您的问题中,您明确询问了吸气剂。 getter 返回有关您的类的一个实例的一些信息。例如,您有一个班级Store
。现在,isStoreOpen
是一个非常好的 getter 方法名称。
接下来,您提到了一种检查所有商店是否都营业的方法。这个方法根本不是一个 getter,因为它不返回关于一个实例的信息,而是返回所有实例的信息。当然除非有课程Stores
。如果是这种情况,您应该重新考虑您的设计,因为 Java 已经有办法存储许多实例,例如数组或集合,因此您不必编写额外的类。
如果不是这种情况,那么这个方法名就很好了。替代方案可能只是 allStoresOpen
没有“is”。
TL;DR:如果您要处理多个实例,则它不是吸气剂。如果是,那么你的设计很糟糕。
【讨论】:
【参考方案10】:老实说,我会说绝对忘记are*
并坚持使用is*
。将"is"
视为变量含义,并尽可能取一个更好的名称。
我想说 isStoresOpen 听起来没有那么糟糕,但如果听起来更适合您,您可以制作 isStoresAreOpen。
但我的总体想法是遵守约定。它对 getter 使用“get”,对布尔类型使用“is”。我个人认为使用“is”有时已经存在问题。是的 - 它在“if”条件下看起来确实不错,但有时我只是在编码时写“get”并检查下拉列表中我需要的变量并开始想知道什么是错的以及为什么我找不到它,然后我意识到它以“是”开头...
【讨论】:
【参考方案11】:在面向对象的编程中,这应该很少发生,如果有的话,因为Store
或Cat
或者你应该是一个单独的类,有自己的isOpen()
或isFuzzy()
方法。如果您有更高的类型,请考虑分解到您实际使用的更原子级别。一般来说,最底层的对象不应该是复数形式。
【讨论】:
【参考方案12】:isStoresOpen() 在这个 StoresOpen 中似乎是复数,
当您遵循 Java 命名约定和 Java Beans 标准时,它们为布尔值和其他类型预定义了前缀,因此您应该遵循 Java Beans 命名约定。
让我们谈谈你的观点 当您将 storesOpen 视为英语预期时,是的,它看起来像复数。 再次深入观察那个词,
这里
storesOpen根据英语语法是复数,
isStoresOpen 的结果不是复数,而是单数,或者您可以说它是编程约定的标量。
出来是布尔值,只是真或假
不像你的英文复数陈述true's或false's
不是 true 或 false 的数组,也不是 true 或 false 的集合
所以,在这里我们可以说,这里我们关心的是从该布尔 bean 方法返回的值,而不是赋予类属性以指向现实世界实体的名称。
更重要的一点是,每当在类中使用此类布尔属性并且这些布尔属性被任何框架中的预定义库使用时,使用前缀 'is' 的框架来检索布尔值, p>
为什么意味着它不像你知道的英语语法如复数/单数、多路复用器等那样聪明...
【讨论】:
以上是关于Java boolean getter "is" vs "are"的主要内容,如果未能解决你的问题,请参考以下文章
java switch(true)的括号里可以是boolean类吗?
传入mybatis的xml为Long型时报There is no getter for property named 'accountId' in 'class java.la