> > Ale to nie odpowiada na pytanie, po co napisał książkę. Kod by napisał, taki
samokomentujący, i by stykło. Nie?
> Równie dobrze mógłbyś pytać, dlaczego nauczyciele prowadzą z uczniami lekcje
czytania.

Zgadzam się, że na logiczną dyskusję chyba nie ma już szans...

> Problem jest podobny do kwestii udostępniania wersji binarnej kompilatora, którego
kod źródłowy jest dostępny.

... tak, jestem tego coraz bardziej pewny. Nie ma szans.

> Błąd, jaki Ty popełniasz, polega na tym, że ze stwierdzenia, że coś jest
dokumentacją, próbujesz wyciągać wniosek, że owo coś jest wyczerpującą albo jedyną
potrzebną dokumentacją.

Bo właśnie tak to działa w powszechnym odbiorze. W sensie - ktoś, kto nie napisał
dokumentacji stwierdza, że przecież jego kod jest tak bardzo samodokumentujący, że
już niczego więcej nie trzeba. I tak to zostaje.
Więc warto jednak dbać o rozróżnianie pojęć, w przeciwnym razie pogubimy się w ich
rozmyciach.
Więc zadbajmy o takie rozróżnienie: kod *nie* jest dokumentacją. Może sobie być
poezją w jakimś pozainżynierskim kontekście (no chyba że poeci zgłoszą jakiś
sprzeciw, np. poczują się obrażeni albo coś), ale nie jest dokumentacją.

> Samodokumentujący kod zawiera wszystko, co jest potrzebne do tego, żeby zrozumieć,
jak jakiś system działa.

"Koń jaki jest, każdy widzi." Wiesz, skąd to zdanie pochodzi? Z bardzo poważnego
źródła. Ale jednak z biegiem czasu zaczęliśmy wymagać więcej, więc nawet w tych
poważnych źródłach już takich zdań nie ma.

> Nie zawiera za to, na przykład, informacji [...]

Bo nie jest dokumentacją.

> Książka Martina jest (kiepskim bo kiepskim, ale jednak) materiałem, który ma
trenować tę umiejętność.

Umiejętność czego? Pisania dobrej jakości kodu? No i świetnie, oby więcej takich
książek.
Nadal jednak kod nie jest dokumentacją.

--
Maciej Sobczak * http://www.inspirel.com