Użytkownik "A.L." napisał w wiadomości grup
dyskusyjnych:353hu8ddr8vgbq5kkva6tlbnk4phsdsuac@4ax.
com...

>Mam watpliwosci. Kod jes twspolna wlasnoscia. Kazdy mzoe zrobic
>zmiany. Jezeli zrobil zmiany, powinien te zmiany udokumentowac. KTO i
>CO. Inaczej zrobi sie niekontrolowany burdel

We wspomnianej książce Robert Martin nie ma nic przeciw "udokumentowywaniu",
jednak uważa, że tego rodzaju (kto np. napisał dany fragment) notki powinny
być w zapisywane osobno, w systemie kontroli wersji. I w czasie pracy nad
tekstem źródłowym programu po prostu ma ich być nie widać.

Autor ma prawo (chyba że go nie ma, tzn. kwestia na ile ma prawa do kodu, a
na ile te prawa ma np. firma) umieszczać informację kto jest autorem danego
dzieła (tj. pliku, fragmentu pliku) wprost w dziele, tj. np. właśnie
wewnątrz pliku. Zwłaszcza, że tego rodzaju wpis nijak nie wpływa na finalny
produkt (tj. nie jest kompilowany itd.)

Jeszcze inaczej: w każdej książce jest napisane, kto jest autorem. Gdyby zaś
konsekwentnie realizować pomysł Martina, to książki nie powinny zawierać
imienia i nazwiska autora, bo przecież te są dostępne w katalogu
bibliotecznym i/lub w bazie danych wydawnictwa.

Po pierwsze, integralność podpisu twórcy i dzieła jest uznawaną praktyką
(podpis Picassa na obrazie Picassa to chyba normalne?).

Po drugie, jest prawdopodobne że informacje o pliku z systemu kontroli
wersji mogą po prostu zaginąć.

Po trzecie, rozwiązania w rodzaju javadoc dobrze się sprawdzają - a przecież
dokumentacja też mogłaby być trzymana osobno, czyż nie...

Teraz kwestia widać-nie-widać. Jeżeli autor podpisał swoje dzieło, to trochę
szczeniackie jest udawać że kod jest anonimowy. A takim udawaniem jest
kasowanie komentarzy zawierających nazwiska autorów lub ukrywanie ich w inny
sposób.