On Sat, 21 Dec 2013 20:09:07 +0100, Przemys??w D?bski
<p...@g...pl> wrote:

>Hej
>
>Wiadomo wszem i wobec, że w trakcie piania kodu warto go opisywać
>komentarzami. Trzeba wyważyć kwestię użyteczności opisu kontra czas
>potrzebny na stworzenie opisu. Skrajność w jedną stronę:
>for(i=0;i<5;i++) informacja że i to licznik pętli jest zbędna. Skrajność
>w drugą stronę: kodujemy projekt, po dwóch miesiącach w trakcie
>tworzenia jakiejś funkcjonalności okazuje się, że dla obecnych potrzeb
>trzeba wstawić w jakąś funkcję nieruszaną od dawien dawna fragment
>kodu, zupełnie niekorespondujący z nazwą funkcji i z tym co ona robi -
>ot po prostu to jest najlepsze miejsce dla tej wstawki. Wiadomo - opisać
>sytuację trzeba.
>
>To są przypadki skrajne, pomiędzy którymi jest milion pierdylionów
>stanów pośrednich. Amatorskie podejście to "hmmm tego mogę kierdyś nie
>zakumać - opiszę", ale i "dam radę - szkoda czasu". Co może doprowadzić
>do tego, że z jednej strony opisujemy niepotrzebnie coś co i tak każdy
>przedszkolak zakuma lub z drugiej stony przeceniamy się i nie opisujemy
>czegoś do czego dzięki opisowi mogli byśmy "szybciej wrócić".
>
>Czy jest jakieś optymalne rozwiązanie ? Przestrzeń rozwiązań chyba spora :)

Proponuje ksiazke

A Guide to Persuasive Programming in Java

by Jerud J. Mead , Anil M. Shende

Mniej wiecej, komentowanie powinno spelnaic role podobna do
mechanizmow "programming by contract"

A.L.