2011-07-28 110 views
44

我们是否应该有一个团队编码标准,抽象类的名称的前缀是Abstract?例如抽象类命名约定

public abstract class AbstractB implements B {} 
+6

我打赌这个问题被关闭。这是非常主观的。不过,我投赞成票。 –

+0

但是,如果你的接口B不能被相同的标准称为InterfaceB – bstick12

+7

@bstick:Nooooo!接口是类型。命名他们是什么! –

回答

62

是的,事实上,如果你看看标准库的javadocs,你会发现左下角框架中的类的列表以抽象类开头,使用你在问题中提到的命名约定。

AbstractAction 
AbstractAnnotationValueVisitor6 
AbstractBorder 
AbstractButton 
AbstractCellEditor 
AbstractCollection 
AbstractColorChooserPanel 
AbstractDocument 
AbstractDocument.AttributeContext 
AbstractDocument.Content 
AbstractDocument.ElementEdit 
AbstractElementVisitor6 
AbstractExecutorService 
AbstractInterruptibleChannel 
AbstractLayoutCache 
AbstractLayoutCache.NodeDimensions 
AbstractList 
AbstractListModel 
AbstractMap 
AbstractMap.SimpleEntry 
AbstractMap.SimpleImmutableEntry 
AbstractMarshallerImpl 
AbstractMethodError 
AbstractOwnableSynchronizer 
AbstractPreferences 
AbstractProcessor 
AbstractQueue 
AbstractQueuedLongSynchronizer 
AbstractQueuedSynchronizer 
AbstractScriptEngine 
AbstractSelectableChannel 
AbstractSelectionKey 
AbstractSelector 
AbstractSequentialList 
AbstractSet 
AbstractSpinnerModel 
AbstractTableModel 
AbstractTypeVisitor6 
AbstractUndoableEdit 
AbstractUnmarshallerImpl 
AbstractWriter 

把他们中的任何一个,说的第一个,并检查其定义:AbstractAction。它确实实现了Action,它又与您的约定类似。它的子类被命名为喜欢:ClosedActionMaximizeAction

+2

计数器例子:java.util.Calendar – KGhatak

+0

@ Susam Pal - 所以,没有实现接口的抽象类应该以'Abstract'开头!注意:卡兰德是一个抽象类 – KGhatak

5

对于可读性,它确实听起来像一个好主意。在阅读代码时,您将能够立即知道课堂内容。只要每个人都遵守这个标准,那就很好。

11

通常任何一种标准都是团队设置中的一件好事。 否则团队成员可能会以只有他们理解的方式命名课程,然后您可以混合使用不同的编码风格,这会导致混淆。

+0

这正是我的想法。我宁愿用Abstract前缀命名它们,但最重要的是遵循团队/项目编码风格。 –

4

当您将鼠标悬停在对象上时,现代IDE将弹出描述性文本。在这种情况下前缀是多余的。

+2

这需要javadocs,整个'团队的另一件事情就是与编码风格的战斗结束。 –

2

我不会说是还是不是在一个答案,但不管你选择,使用一个很好的static analysis tool,以确保它。

2

与这种类型的大多数问题一样:“取决于”。我喜欢一致性和清晰度,所以如果它适合你和你的店铺,那很好。但是,如果您有传统的抽象类,那么您将希望返回并将它们重构为相同的命名约定。