抽象类命名约定

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

 public abstract class AbstractB implements B {} 

是的,实际上,如果您查看http://download.oracle.com/javase/6/docs/api/上的标准库的javadoc,则会发现左下angular框架中的类列表以抽象类使用您在问题中提到的命名约定。;

 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

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

对于可读性来说,这听起来像是个好主意。 在阅读代码时,你将能够立即知道课程是什么。 只要每个人都遵守这个标准,那就很好。

当您hover在对象上时,现代IDE将popup描述性文本。 在这种情况下前缀是多余的。

在回答中,我不会说或者不回答,但是无论你select什么,都要使用一个好的静态分析工具来确保它。

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