2011-07-28 148 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

與這種類型的大多數問題一樣:「取決於」。我喜歡一致性和清晰度,所以如果它適合你和你的店鋪,那很好。但是,如果您有傳統的抽象類,那麼您將希望返回並將它們重構爲相同的命名約定。