[英]Java Interface, AbstractClass and Enum naming convention
我們正在我們的團隊中討論 Java 的代碼約定:
interface
: Foo
或IFoo
或FooInterface
?
abstract
: Foo
還是AbstractFoo
?
Enums
: Foo
還是FooEnum
?
我基本上是想把我的個人喜好放在一邊:) 所以非常歡迎支持一個或其他約定的理由。
在 Java 中: Foo
、 AbstractFoo
和Foo
- 盡管AbstractFoo
可能只是Foo
。
證據:
java.util.List
(接口)java.util.AbstractList
(抽象類)java.util.Formatter.BigDecimalLayoutForm
(枚舉)對於接口部分,請參閱 Java 編碼約定文檔的命名約定部分。 不過,它沒有談論枚舉和抽象類。
從我的博客:
該博客還討論了反對其他一些名稱的原因。
接口:Foo
原因:您的代碼一定不需要知道它們正在處理接口。 寫 'IFoo' 就是這樣做的。 相反,Foo 明確表示 'Foo' 是通用的,它后面的 object 可能是 'NumFoo' 或 'StrFoo'。 代碼真的不用管。
抽象類:AbstractFoo
原因:您的代碼永遠不會直接使用這個 class。 您將始終將此 class 子類化以創建其他代碼使用的任何類。 所以程序員必須非常清楚 class 是一個抽象的。 還有什么更好的方式將其命名為 Abstract,需要使用 AbstractFoo 類型引用的地方。 你應該重新考慮使用接口,(當然,這在 C++ 中是不可能的)
枚舉:FooType或 FooEnum。 就個人而言,FooType 更好,因為 Type 更容易與 Enum 所做的“現實世界”相關聯。
干杯!
沒有特別約定。
對這些類型的類有特殊的命名約定基本上是匈牙利符號的一種形式(不好的那種):它給你的信息已經存在於語法中並且通常可以通過 IDE 輕松獲得,例如當你在名稱上輸入 hover 時。 將其放入名稱本身是毫無意義且丑陋的。
Class 名稱應該盡可能簡單地描述類的角色。 這可能會導致“自然”命名約定——一個很好的例子是 Java 命名接口約定,帶有 -able 后綴(Iterable,Comparable)——但我不想想象如果它被普遍強制執行和 List 的結果, Map等只好跟進。
我的約定:
我真的不喜歡在接口名稱甚至 FooInterface 中使用 I:
interface FooInterface {
就像寫:
class FooClass {
甚至:
abstract class AbstractFooClass {
這簡直是冗長的。
我的約定:
Foo
;AbstractFoo
;Foo
但在某些情況下FooType
。 IFoo
是很.Net的,不是FooInterface
我沒見過用過的。
關於我個人喜歡的界面:
Fooable
關於接口:
我更喜歡 IFoo,因為它是一個會說話的名字,可以立即告訴您它是一個接口。 其次,對於只為一個 class 做接口的模塊等,class 通常與接口同名。 然后你可以使用 Foo extends IFoo。 否則,好吧,你必須找到一個名字。 或者使用 FooInterface 或其他什么……
java.util.list 如上所述使用 Foo。 這沒有問題,因為具有不同概念的類實現了它,因此已經建議了不同的名稱(ArrayList、LinkedList ……)。 我不太確定我是否真的更喜歡那里的 IList。 不知道……:P
這是我在 ION 的開發團隊中使用的約定。
界面
interface IMyInterface
:::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::: ::::::::::::
abstract class MyAbstract
:::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::: ::::::::::::
enum EMyEnumeration
:::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::: ::::::::::::
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.