2009-09-02 16 views

回答

20

根據代碼完整,評論用於說明代碼的目的。將其用於其他目的可能會導致「評論衰退」。這就是說,跟蹤代碼所有權,更改日誌和最後修改文件的人,恕我直言,是像SVN等源代碼控制回購的工作,不應該在評論中。除非它是某種許可證。或者使用IDE的書籤系統來跟蹤誰創作了一個函數,誰負責它。

雖然這只是我2分錢的價值。

16

如果代碼是源代碼控制之下,沒有。
這種數據應該存儲在源代碼庫中。

如果代碼要廣泛分佈(在沒有任何類型的存儲庫的其他環境中),那麼是的,這可能是有用的。 (一些Java源代碼確實包含這方面的信息,以及從該代碼的某些進化可用的版本號)

顯然這方面的信息(廣泛部署的代碼庫)是在文件水平只要。
考慮例如java.lang.Boolean中的Java源代碼:

/** 
* [...] 
* In addition, this class provides many methods for 
* converting a {@code boolean} to a {@code String} and a 
* {@code String} to a {@code boolean}, as well as other 
* constants and methods useful when dealing with a 
* {@code boolean}. 
* 
* @author Arthur van Hoff 
* @version 1.60, 05/05/07 
* @since JDK1.0 
*/ 
public final class Boolean implements java.io.Serializable, 
    Comparable<Boolean> { 
[...] 

您不必全部由剛開始的時候,作者,只有最近的一個,與相關的最後一個主要版本最近一次修改,以及該類原始介紹的版本。

例如,當您想維護良好的API時,可以幫助API tooling

但是關於作者的信息仍然侷限於文件,而不是函數:他代表類中所有函數的協調器或聚合管理器,即使可能有多個貢獻者隨時間推移。

因此,這是一個公共信息,值得被放在明確的文件,而不是一個私人元數據(誰寫的東西),存儲所有其他元數據(日期,版本,分支,合併信息,...)在源代碼庫中。

+0

...用於*每一個功能*?一個班級有多少位作者?對於全班同學來說,指定他們一次還不夠嗎? – 2009-09-02 09:26:57

+0

@Konrad:真的,我指的是OP的問題的「甚至文件」部分。我沒有看到有關功能的信息。 – VonC 2009-09-02 10:13:19

+0

即使在有意義的情況下,作者和版本信息也應該使用正在使用的VCS的RCS關鍵字功能進行標記。依靠工程師手動維護這些信息*將*導致註釋文件中的信息不準確。 – 2009-10-06 13:33:31

1

不是。您或您所在公司的隱含版權擁有版權。但是爲了追蹤目的,可以向這個人詢問這段代碼後面做了什麼。

+1

這就是SCC的用途...... – 2009-09-02 08:43:23

+0

我不確定版權聲明可以放在元數據中。但VonC的答案更完整。 – 2009-09-07 10:18:29

-1

是的,它是必要的。另外如果可能的話,給出日期和名字。它用於跟蹤目的,並賦予其他人知道該功能的所有者的權利。

2

是代碼將在源控制

然後沒有。源代碼管理負責跟蹤這個(blame)。

尤其對於團隊OpenSource項目,指示特定代碼段的作者可能是有用的或必要的。但是評論每一個功能看起來真的太過分了,特別是因爲大部分的課程都是由同一個作者編寫的(n'est-ce pas?)。我喜歡指定每個類的作者的Java庫慣例。不知何故,這似乎是正確的權衡。

另一方面,如果您合作創作了一堂課,那麼如果有人在其中寫入了錯誤的代碼,那麼您應該責怪自己。我其實認爲這是一個好的的事情。一個類(至少在OOP中)是一個實體,因此質量取決於其整體質量。如果一個功能不好,全班同樣如此。

0

在某些項目中,可以使用作者姓名給予比他預期的更多努力進行開發的人的應有功勞。這種認可可以提高動力。