我们正在团队中讨论Java的代码约定:
interface
:Foo
或IFoo
或FooInterface
?
abstract
:Foo
或AbstractFoo
?
Enums
:Foo
或FooEnum
?
我基本上试图将我的个人偏好放在一边:)所以非常欢迎支持一个或其他约定的理由。
答案 0 :(得分:29)
在Java中:Foo
,AbstractFoo
和Foo
- 尽管AbstractFoo
可能只是Foo
。
证据:
java.util.List
(界面)java.util.AbstractList
(抽象类)java.util.Formatter.BigDecimalLayoutForm
(枚举)有关接口部分,请参阅Java编码约定文档的Naming Conventions部分。它不讨论枚举和抽象类。
答案 1 :(得分:18)
接口:Foo
原因:您的代码不必知道他们正在处理接口。写'IFoo'就是这么做的。相反,Foo清楚地表明'Foo'是通用的,它背后的对象可能是'NumFoo'或'StrFoo'。代码真的不需要关心。
抽象类:AbstractFoo
原因:您的代码永远不会直接使用此类。您将始终将此类子类化以生成其他代码使用的任何类。因此,程序员必须清楚地知道该类是抽象类。有什么更好的方法来命名它抽象! 您需要使用AbstractFoo类型的引用的地方,您应该重新考虑使用接口。 (当然,这在C ++中是不可能的)
枚举:FooType 或FooEnum。就个人而言,FooType更好,因为Type更容易与Enum所做的“现实世界”相关联。
干杯!
答案 2 :(得分:17)
来自my blog:
该博客还讨论了一些其他名称的原因。
答案 3 :(得分:5)
没有特别的约定。
对这些类具有特殊的命名约定基本上是一种匈牙利符号(坏类型):它给出的信息已经存在于语法中,并且通常可以由IDE轻松获得,例如:当您将鼠标悬停在名称上时。将它放入名称本身是毫无意义和丑陋的。
类名应该简单地描述类的角色。这个可以导致“自然”的命名约定 - 一个非常好的例子是使用-able后缀(Iterable,Comparable)命名接口的Java约定 - 但我不想想象结果如果它是普遍执行的,List,Map等必须遵循它。
答案 4 :(得分:3)
我的约定:
我真的不喜欢在界面名称中使用I,甚至不喜欢FooInterface:
interface FooInterface {
就像写作:
class FooClass {
甚至:
abstract class AbstractFooClass {
它只是一个长子。
答案 5 :(得分:2)
我的约定:
Foo
; AbstractFoo
; Foo
,但在某些情况下FooType
。 IFoo
非常.Net,而不是Java。 FooInterface
我从未见过用过。
答案 6 :(得分:2)
关于我个人喜欢的界面:
Fooable
答案 7 :(得分:1)
关于界面:
我更喜欢IFoo,因为它是一个会说话的名字,告诉你它是一个立刻的界面。 其次,对于只为一个类执行接口的模块等,该类通常与接口具有相同的名称。然后你可以使用Foo扩展IFoo。否则,你必须找到一个名字。或者使用FooInterface或其他......
java.util.list如上所述使用Foo。这没有问题,因为具有不同概念的类实现它,因此已经建议了不同的名称(ArrayList,LinkedList ...)。 我不太确定我是否真的更喜欢IList。 Dunno ......:P
答案 8 :(得分:0)
这是我在ION的DEV团队中使用的对话。
<强>接口强>
interface IMyInterface
::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::
abstract class MyAbstract
::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::
enum EMyEnumeration
::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::